<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Cost Archives | Cloudar</title>
	<atom:link href="https://cloudar.be/tag/cost/feed/" rel="self" type="application/rss+xml" />
	<link>https://cloudar.be/tag/cost/</link>
	<description>100% Focus On AWS // 100% Customer Obsession</description>
	<lastBuildDate>Tue, 22 Nov 2016 11:44:20 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.4</generator>
	<item>
		<title>Using Route53 to support on-demand applications</title>
		<link>https://cloudar.be/awsblog/using-route53-to-support-on-demand-applications/</link>
					<comments>https://cloudar.be/awsblog/using-route53-to-support-on-demand-applications/#respond</comments>
		
		<dc:creator><![CDATA[Ben Bridts]]></dc:creator>
		<pubDate>Tue, 22 Nov 2016 11:44:20 +0000</pubDate>
				<category><![CDATA[AWS Blog]]></category>
		<category><![CDATA[CloudFront]]></category>
		<category><![CDATA[Cost]]></category>
		<category><![CDATA[Lambda]]></category>
		<category><![CDATA[Route53]]></category>
		<guid isPermaLink="false">https://cloudar.be/?p=3670</guid>

					<description><![CDATA[<p>One of the best ways to save money on AWS is turning resources off when you don&#8217;t use them. This is pretty easy to automate if you have consistent usage patterns (like an application that&#8217;s only used during business hours), but can be harder if the usage is very irregular (for example an application that&#8217;s [&#8230;]</p>
<p>The post <a href="https://cloudar.be/awsblog/using-route53-to-support-on-demand-applications/">Using Route53 to support on-demand applications</a> appeared first on <a href="https://cloudar.be">Cloudar</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>One of the best ways to save money on AWS is turning resources off when you don&#8217;t use them. This is pretty easy to automate if you have consistent usage patterns (like an application that&#8217;s only used during business hours), but can be harder if the usage is very irregular (for example an application that&#8217;s only used a few times per quarter).</p>
<p>We recently worked with a customer that had some applications that could be without usage for months. To be more cost efficient, they were looking for a solution where:</p>
<ul>
<li>They could turn off as much instances and services as possible</li>
<li>The users could start the application with one button click if they needed to use it</li>
<li>The users didn&#8217;t have AWS credentials</li>
</ul>
<p>We came up with the following solution to satisfy these requirements, and if you&#8217;re running the same kind of applications, maybe you can also reduce costs by implementing this.</p>
<p><img fetchpriority="high" decoding="async" src="https://cloudar.be/wp-content/uploads/2016/11/Untitled-15.png" alt="" width="730" height="815" class="alignnone size-full wp-image-5971" srcset="https://cloudar.be/wp-content/uploads/2016/11/Untitled-15.png 730w, https://cloudar.be/wp-content/uploads/2016/11/Untitled-15-645x720.png 645w" sizes="(max-width: 730px) 100vw, 730px" /></p>
<p>This solutions works by taking advantage of the Route53 health checks. We&#8217;ve split up our infrastructure in two parts: an always-on part that uses low cost or usage based services to provide the user with a way to start the real application; and a part that can started and stopped on demand.</p>
<p>We configure the on-demand part to be the primary resource in Route53 and the always-on part as a failover. This way the traffic will be routed to the real application if it&#8217;s online, and the user will get a static webpage that gives him the option to start the application if it&#8217;s not.</p>
<p>If we look at how this would go if the application is offline, these are the steps that would happen:</p>
<ol>
<li>The user requests the DNS record for application.example.com from Route53. Because the real application is offline, Route53 will respond with the recordset of the fallback CloudFront distribution.</li>
<li>The user request a page from CloudFront. CloudFront will get this from S3 and serve it to the user. This page contains an explanation of why the application is not available and a button to start it.</li>
<li>When the user clicks the button, it uses javascript to call the API Gateway and invoke a lambda function.</li>
<li>The lambda function calls Service Catalog or CloudFormation (depending on your environment) to start the real application</li>
<li>When the application has started, the health check will pass, and Route53 will start returning the recordset for the CloudFront distribution that is linked to the application</li>
<li>When the user uses the new DNS records, it will go through the second CloudFront distribution and to the real application</li>
</ol>
<p>Some things to keep in mind.</p>
<p>This only a high level overview of a possible solution. To implement this, you would also have to consider the following:</p>
<ul>
<li>After starting the Application, the static webpage should refresh the page, to force the browser to do a new DNS lookup.</li>
<li>CloudFront will cache errors for 5 minutes by default. Decreasing this will make the failover go faster.</li>
<li>The TTL of an CloudFront DNS record is 60 seconds</li>
</ul>
<p>The post <a href="https://cloudar.be/awsblog/using-route53-to-support-on-demand-applications/">Using Route53 to support on-demand applications</a> appeared first on <a href="https://cloudar.be">Cloudar</a>.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://cloudar.be/awsblog/using-route53-to-support-on-demand-applications/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
