Get Your Landers Up And Running On A CDN - The Simplest, Lowest-Cost Way Ever! (72)
Get Your Landers Up And Running On A CDN - The Simplest, Lowest-Cost Way Ever!
One of the more confusing parts of getting started in AM is setting up your hosting environment. That's arguably even more complicated these days - not only do you need to set up a server, but you'll also need to set up a Content Delivery Network (CDN) to make sure your landers get to every geo as fast as possible.
However, things are getting easier. Zeno and Vortex recently put me on to the simplest, cheapest way to get your landers set up on a CDN I've ever seen.
We'll be using Amazon's S3 and Cloudfront services. S3 used to be horrendously techie and very hard to use, but it's had a total revamp lately, and it's now incredibly easy and fast. No coding, not even any dedicated tools - just set and go in your web browser.
Let's Go!
Who This Tutorial Is For
This tutorial gives you a fast, easy onramp to getting your landers onto a decent CDN so that you can get on with testing your campaigns. It'll mostly be useful for new affiliates, although anyone wanting to move to a CDN-based approach can use it to achieve solid results.
This server setup is a Minimum Effective Dose approach. It gives the fastest, most cost-effective approach to a hosting solution that's good enough that you don't need to worry about it. You can get started and concentrate on learning more core aspects of AM, or rapidly upgrade your single-server approach. If you want to go beyond that to optimise your setup, see "Addendum: Other CDNs" below.
You'll need to be using
What You'll Need And What You Won't
You'll need to have a landing page that you'd like to deploy ready to go. That can be for any kind of campaign - pop, mobile, whatever. The landing page can't have any PHP or other server-side code on it, but Javascript is fine.
You'll need to have registered a domain name. You'll also need an Amazon account.
And that's it! You don't need any coding or even HTML knowledge, and you don't need any tools - all of this setup is done through the Web.
Stages Of The Tutorial
Firstly, we'll set up an S3 bucket. That's confusing Amazon-speak for setting up a folder on the Web where you can store your files, much like Dropbox - in fact, it's the service Dropbox runs on. You can actually use this "bucket" to make your landing pages accessible directly to your visitors, but that's not a very good idea, as S3's Web serving is pretty slow.
Secondly, we'll upload your lander to this "bucket". We don't need an FTP tool for this - it's all doable in the browser.
Thirdly, we'll set up a "distribution" on Cloudfront, Amazon's CDN. Because we're doing all this within the Amazon infrastructure, this is very quick and easy. It'll take about 15 minutes to propagate through Amazon's systems: after that, anything you put in your "bucket" will be accessible anywhere in the world through the CDN, which will ensure that the files are served from a server close to your visitors.
Finally, we'll connect your domain name to all this, meaning that if you upload a file called "lander.html" to your bucket, it's then accessible on the web at http://www.youdomain.com/lander.html .
And that's all we need to do to set up a reasonably optimised CDN-based solution for landing pages.
Stage 1: S3 Bucket
This is actually the most complicated stage of the entire process, but even this doesn't take more than 8 minutes or so.
Go to https://aws.amazon.com/s3/ and sign up or sign in. You should end up (after the signup process) at a page that looks like this:
Yeah, Amazon has a lot of stuff - but we don't need most of it. Click on the S3 button. You'll go to a mostly empty page with a button called "Create Bucket" in the top left.
Click it, and you'll be presented with this screen:
In "Bucket Name", put your domain name - so, "www.mydomain.com" or whatever you have.
TIP: You don't actually have to use your domain as the bucket name - it just makes it easier to organise things. So if your domain's already taken as a bucket name, choose whatever you like.
The Region you choose isn't relevant - choose the default or pick your favourite area!
Click "Create". Now you'll be presented with a screen like this:
There are two things to do here. Firstly, click on "Static Website Hosting", and choose "Enable Website Hosting" from the panel that appears. Set the index page to "index.html" and the error page to "404.html". Then hit "Save".
Copy the website address it gives in this section to a text file - we'll need it later.
The second thing is a little more complex, and is about the only complex part of the operation. Click on "Permissions", and then click on "Add Bucket Policy" on the panel that appears. You'll see a textbox appear in the middle of the screen.
What we're going to do here is set all files in the bucket to be accessible from the Web by default. If we don't do this, we'll have to set "make public" individually on everything we upload, which is a huge pain in the ass and very easy to screw up. Unfortunately, this is the one part of the process that doesn't have a nice easy graphical interface - instead, we have to copy some code. Fortunately, it's the same code every time.
TIP: You don't need to understand this code at all! If you don't understand what it's doing, don't give it a second thought: this is some Deep Techie stuff and its precise meaning isn't relevant to what we want to do. Just copy-paste it, change the bucket name to your bucket name, and it'll work: no coding or understanding of the code required.
Copy-paste the following into that textbox (changing "MYBUCKET" in the code to the name of your S3 Bucket):
{
"Version":"2012-10-17",
"Statement":[{
"Sid":"PublicReadGetObject",
"Effect":"Allow",
"Principal": "*",
"Action":["s3:GetObject"],
"Resource":["arn:aws:s3:::MYBUCKET/*"
]
}
]
}
That's our bucket set up!
Now, let's upload our first landing page.
Stage 2: Uploading A Landing Page
Click on your bucket name on the left-hand side of the page - you'll go to a screen like this:
Click on "Actions", then click on "Upload".
In the new window that comes up, click on "Add Files", and select all the files for your landing page - including images and any Javascript or styles. Then click "Start Upload" at the bottom right.
And that's it: your landing page is now publicly accessible. Go to the website address you saved in Stage 1, with the filename of your lander at the end of it: for example,
www.mydomain.com.s3-website-us-west-1.amazonaws.com/landingpage.html
You should see your lander there!
Next, we add in the CDN magic.
Stage 3: Cloudfront Setup
At the top left of the page, click on "Services", then hover over "Storage And Content Delivery". You should see "Cloudfront" listed - click on it.
Click "Create Distribution" at the top left - it's the big blue button.
You'll be taken to a page where you choose between "Web" and "RTMP" - choose "Web" by clicking "Get Started" underneath the "Web" section.
You'll be taken to this page, which more or less screams "If you are not actually wearing a propeller hat RIGHT NOW, Go No Further!". Don't panic; it's far simpler than it looks:
Click in the text box next to "Origin Domain Name". You'll see it bring up a list of your S3 buckets - choose the one you just created.
And you're done. No, really. All the other options are, well, optional. Scroll down to the bottom and click "Create Distribution" on the bottom-right.
The Cloudfront page will come up again, looking a bit like this:
"In Progress" will change to "deployed" in about 15 minutes, at which point your files will be accessible. But in the meantime, let's set up your DNS!
Firstly, in your Cloudfront panel, click on your distribution, go to "Distribution Settings", then click "Edit" at the top left.
In "Alternate Domain Names(CNAMEs)", add the domain name you intend to use (including www. if you plan to send traffic to, for example, www.mydomain.com). Hit "Yes, Edit" at the bottom right. Again, this will take about 15 minutes to take effect.
Copy the "domain name" from here to a text file - you'll use it in the next stage.
Setting Up Your DNS
You should set up a CNAME record for your www.domainname, with the domain name you copied from Cloudfront as the record in question.
How exactly you do that will vary from DNS provider to DNS provider, but in 99% of all cases they should have good documentation available showing exactly how to do it.
Our #1 recommended approach here is to use Amazon's own DNS provider, Route 53 - which has the advantage of being super-fast. Here's the official STM tutorial on how to do that: https://stmforum.com/forum/showthrea...iliates-Bother , specifically tailored to work with this guide.
If you'd prefer not to do that, you can also use another DNS provider. Here are some non-affiliate specific tutorials on how to add a CNAME record on:
If you have problems with any other DNS providers, let me know below and I'll help out!
And That's It!
Once you've gone through all these steps, wait about half an hour, and check that the Cloudfront distribution is now listed as "deployed".
Now, go to your domain name followed by your landing page filename - http://www.mydomain.com/landingpage.html .
You should see that immediately appear. It's now being served through the CDN, so no matter where in the world you are, it should also load fast - at least the second time you load it and beyond.
To check out how fast your lander now loads from around the world, you can use a tool like https://www.dotcom-tools.com/website-speed-test.aspx .
And that's it! We've set up your "server" (your S3 bucket) and configured a CDN to work with it. From now on, you can just use the Upload tool in stage 2 to upload your landers to your Bucket, and they'll appear on the Web instantly, all ready with CDN goodness to serve any geo in the world.
One quirk - if you need to delete a file from Cloudfront, it's tricky to do. If you have to, you can submit an Invalidation Request, but that takes 30 minutes or so to work. The simplest workarounds for the deletion problem are:
- If you're testing your lander and aren't ready to send traffic to it yet, check it through your S3 bucket address, NOT your domain name or Cloudfront address. This means it doesn't get loaded into Cloudfront, and will change whenever you change it. Only use your domain name when you're ready to go.
- If you do need to change something on Cloudfront quickly, just upload the updated version of whatever you changed as a slightly different filename - Landingpage_v2.html, for example. That will then be fetched by Cloudfront as normal.
I hope that was useful! If you have any questions, comments, or suggestions on how to improve the process - I'm comparatively new to Amazon's services - do comment below!
Addendum: Other CDNs
In the past, I've recommended you don't use Amazon services, because they're slow. So why am I recommending Cloudfront now, and what other options could you go for?
To answer the first part: Amazon EC2 servers, at least the small ones, are terrible for AM purposes, particularly running tracking. However, Cloudfront's a completely different part of their company, and hosting landing pages is a very different problem from running a tracker.
Cloudfront has a lot of advantages newer affiliates in particular, which is why I've chosen it for this tutorial:
- It's a capable CDN from a speed point of view, testing about as fast as Akamai and generally better than Cloudflare (in limited tests, admittedly - see below).
- It has very generous seeding policies. Whilst other CDNs will require a file to be hit multiple times a minute before they start speeding it up - MaxCDN's particularly bad for this in my experience - Cloudfront holds files in cache after a single hit for 24 hours. That means that even low-volume campaigns will benefit.
- Its pricing is comparable with other CDNs, but it doesn't have a minimum spend. That's a big deal for new affiliates with lower budgets. For example, all my testing for this tutorial cost a grand total of $0.13. There's also a free tier of Cloudfront usage, which is pretty generous - chances are if you're running a few thousand clicks a day or less, you'll not pay for Cloudfront at all for the first year you're signed up to AWS.
- It's easy to use for non-technical people. It's not the easiest CDN I've seen - that honour goes to Beyond Hosting's CDN, which is even easier to use - but it's one of the easiest to operate.
Once you get more advanced with your CDN usage, there's every chance that you can squeeze more ROI from your campaigns by looking at getting a dedicated server close to the geos you're targeting, or using a tool like Cedexis.
Zeno wrote a great guide to over here to choose the CDN with the most bang for your buck in your geo.
Hey caurmen,
thanks for this favolous guide!
Have you did tests VPS vs this CDN solution?
I'd love to see the actual different of implementing this!
Thanks
Yep, I did a bunch of testing as due dilligence before I wrote this to make sure that it was actually faster than a single server.
Using a single highly-optimised VPS in London vs a Cloudfront distribution, loading a not-terribly-optimised mobile page, I saw:
- Slower load times in London for the Cloudfront distro, by 300ms or so. Not surprising - I've yet to find a time when a CDN will beat a well-peered, well-configured VPS if both are local to the user.
- Load times about equivalent in Western Europe - VPS was slightly faster in Amsterdam, surprisingly.
- CDN half a second faster, at around 400ms load time, in the USA.
- CDN a second faster in Buenos Aires - I'd expect load times to be even faster in other LATAM areas given that Amazon's points of presence are in Brazil.
- CDN more than a second faster in Japan.
- CDN more than two seconds faster (!) in Australia.
Overall Cloudfront didn't have load times significantly over a second anywhere, apart from something weird in Mumbai on one test (which I think may be a misconfiguration on my end), and was around half a second in most places. That's using the website load time tool I've referenced above, which seems to spit out slower loading times in general than Pingdom's tester.
I didn't do a comparative test using Pingdom's tester, but did test a bunch of locations with it too - nothing over 200ms there, including AU.
Hi caurmen,
Cloudfront seems do not refresh cache file immediately after we updated the same file. Should I change TTL manually or there is some other setting I can use which I am struggling to find.
@digitoma - That's a very good question, and one I'll update the tutorial to cover.
The simplest way - but with drawbacks - is indeed to reduce the TTL right down until you've got your final version of the file up. However, that only works if you remember to do it before you first access the file through Cloudfront. Also, if you do this be very certain to re-set the TTL back up after you've finished. If you launch a campaign with a TTL of 0, Cloudfront will sit there helpfully slowing every request down...
The second option is to submit an "Invalidation Request" through the Cloudfront console. It takes 5-15 minutes, though: http://docs.aws.amazon.com/AmazonClo...alidation.html
And finally, the workaround suggested by Amazon is just to slightly rename the file you've changed and then reference that. It's a bit of a pain in the ass, but to be honest, when working with simple landers it's my go-to option. Works less well if you've changed images or similar, though.
Finally-finally: remember you can still access your files through the S3 bucket directly. If you're uploading to test that everything works, I'd recommend just checking repeatedly via the S3 bucket address and not using your actual domain name until you set it live.
Hope that helps!
(Anyone else reading this and finding it confusing - don't worry, I'll update the tutorial with the cleaned-up version of this HOWTO next week.)
Great write up man. All this shit always confused the hell outta me. Especially anything with Amazon.
Originally Posted by digitoma
super thanks caurmen!
bit confused why i can't access the domain. i already do the CNAME like the video tutorial, and wait for 30-60 minutes..
but this is what i got
http://prntscr.com/87ojly
i also try another bucket, use internet.bs as a registrar, add CNAME and wait 60 minutes also, but same result happen, any idea why this happen?
Thanks in advance
Does anyone have any stats relating to increased conversions using a CDN? Just wondering if a little bit faster speeds actually does make a difference. I would think in some campaigns it really wouldnt make that much of a difference but I may be wrong. I guess in countries in LATAM its a no brainer, most of my traffic however is in the US so I doubt it would make much of a difference in my case since my server is in the US as well.
Thanks for this tutorial!
Btw, how's Amazon compare with Rackspace?
Is there any different in usage between them?
Originally Posted by lord_imaji
I'm also having the same issue, same error as lord_imaji. Not sure if it's replication time issue
Any advise?
Originally Posted by lord_imaji
I'm having the same issue of not being able to see my domain after following all the steps. My registrar is namecheap and I have added the cname, for this your DNS must be pointing to namecheap servers so you have the option "all host records" as per the video tutorial.
This is what i have done so far: Got a domain name, created the S3 bucket, upload the files, Created Distribution in cloud front and added the cname in namecheap as per instructions but still getting an error when loading my domain.
maybe a silly question but, don't we have to setup the DNS as well to point to amazon?
@vanyan I'm having the same problem, just spoke to namecheap who've said my CNAME is fine. They suggest getting in contact with amazon...
1. DNS entries should never have protocols or filenames in them. Remove any http:// or /filenames, they are never used in DNS entries.
2. I'm still unsure if you guys are loading domain.com, or domain.com/file_that_actually_exists, please do confirm this and actually load the full path of something and it's giving that error.
@vidivo - I did do a test on whether it was worth using a CDN in the US a while back. Measured load times rather than ROI, but based on that, the answer is "no" - load times were almost identical, if not slightly faster from a US-based single server.
@anju92 - that setup looks good. Is it working OK?
@mrchow - I've not tested Rackspace extensively, but I understand from Zeno that they have a very solid CDN. Probably a little trickier to set up than Cloudfront just because they're outside the Amazon ecosystem, but there's no reason not to use them, beyond that, of which I am aware.
subscribed!
Originally Posted by zeno
Looking at the tutorial, you should have the option of "all host records" in namecheap in order to be able to add a CNAME
I created the S3 bucket in ireland region, then when creating the new distribution in CF - I select the bucket I created previously as per instructions.
I have tried to load my domain.com and also mydomain.com/name_of_my_file (in this case index.html) but I always get this error:
ERROR
The request could not be satisfied.
Bad request.
Generated by cloudfront (CloudFront)
Request ID: 1Fw_RxIwi_ofF5BxSSWmgnmLIN27X7LqKsmlfPQveiRY01Tu-PAlKA==
Also, my domain name DNS is pointing to namecheap server like I said, otherwise I have no way to add a CNAME
Am I missing something?
just wondering whether it would make a difference if I use the bucket's/cloudfront's domain instead of my own domain. I saw a post about testing and not showing any real difference even with scamy domains vs domains related to offer. Do you think I have any disadvantages not using my domain?
@vanyam does your raw CF distribution URL work fine? If not, that's the place to start. You should also check that your raw bucket URL works, i.e.
www.mydomain.com.s3-website-us-west-1.amazonaws.com/landingpage.html
In that case, try using a different browser, flushing your DNS cache, or checking through a VPN.
@anuj92 - Does the page load OK if you go through the Cloudfront distribution URL? We will get this up and running!
@caurmen, yep it works just using the cloudfront dist URL, I've tried using a different browser, flushing my DNS cache and accessing it via a VPN - still doesnt work
I've done it with both the CF distribution and the Raw bucket, and it works.
Yep. I think all of us having the same problem.
- We use the raw bucket URL -> It work (mybucket.s3-website-us-east-1.amazonaws.com/index.html)
- We use the raw cloudfrount URL -> It work (izzzz39b3m6g5.cloudfront.net/index.html)
- Use namecheap, DNS still pointing default to namecheap, set the CNAME with : izzzz39b3m6g5.cloudfront.net (for the www & mysubdomain, without http:// or any file e.g index.html)
but the result when you try to access www.mydomain.com/index.html or subdomain.mydomain.com/index.html is :
ERROR
The request could not be satisfied.
Bad request.
Generated by cloudfront (CloudFront)
Request ID: 1Fw_RxIwi_ofF5BxSSWmgnmLIN27X7LqKsmlfPQveiRY01Tu-PAlKA==
--------------------------------------------------------------
Anyway if we use this CDN, is any thing related to PHP command will not work? let say e.g for geo callout using php.
Originally Posted by balint
Whether the lander seems 'scammy' due to the destination URL is not clear and requires some much needed split testing.
Another thing to keep in mind. I see so many people using variations of the word track in their tracking domains. Makes it so much easier to get blocked by most ad blockers. Pick something more generic.
It's not going to be 100% perfect. The other half of the equation is to remove footprints from the tracking URL.
Working on a solution that will allow you to eliminate all traces of p202 from links and pixels.
Thanks Caurmen, I now have it working and the landers are hosted on domain.com and tracking setup on track.domain.com.
Mr Baffoe, you bring up a good point so I might change the tracking subdomain to something more generic to avoid being blocked as often. How much of an impact are we talking? Should I just go ahead and switch to a generic subdomain name since I'm just starting out anyways?
Thanks
Yes, I'd recommend just switching to a generic subdomain now. There's no downside and a not-insignificant upside, as mentioned.
Perfect will do, I really appreciate the insights!
Still learning a lot about how it all comes together with the help of all the guides here. Still working on getting to editing LP's with @Vortex guide. But I got a question about this guide and this setup, Route 53 to Cloudfront to S3 Bucket, do I still need any other hosting like a Vps for my domain, cos I'm on DigitalOcean?
I also do not use
Would it be recommended to have CpvLab on the same domain for LP's using this, or would be too much cost if domain is on Route 53, or should I just have one subdomain for CpvLab on DigitalOcean?
Startup cost is very important as it has been mentioned time and time again, my goal is with the help of the forum, I can get a very low but efficient setup to start with, run campaign and learn the first commandment of CPA marketing, which for me is learning, knowing the basics and once I get that down to the teeth, questions about optimization would be next.
The basics are : understanding basic html, ripping and editing LP's, hosting and setup for LP and Tracking. I have Adplexity, Domains and STM right now, had
@shynepapin:
I'd recommend using a different subdomain for CPVLab, yes. That's easy enough to set up on Route53, and doesn't attract significant extra costs.
(Don't use track.domain.com though. Use something else that doesn't immediately reveal it's a tracker.)
As far as hosting goes, you can either host your landers on S3 or on the same VPS that you're hosting CPVLab on. This guide's setup will work fine for hosting your landers on S3 - you will still need a separate VPS server for CPVLab, though.
Does that make sense? Let me know if you need any more clarification.
Originally Posted by caurmen
For optimal fast and reliable performance of landing pages, what would you recommend? VPS + Cloudflare or S3 + Cloudfront?
I've always used the FTP upload, add php redirect script for custom URL, e.g domain.con/index.html to domain.com/story.php because of PPC campaigns approvals. Now, I'm starting over with Mobile, learning html gradually so I can keep up with mass campaigns with ripping Landers, I've always built LP's from scratch using instabuilder, export html and upload to my domain. I wouldn't want to take up to much of your time, there's just so much information here for techy noobs and it's overwhelming and any expanciated walkthrough would be appreciated.
No problem at all - ask away! That's what us mods are here for.
The approach you're used to using will work absolutely fine with a decent CDN. No need to switch to S3.
Fire your next question!
Originally Posted by caurmen
Wll appreciated.
Ok, let's say I use cpvlab on my vps from digitaocean. I still think the S3 route for Lp's is the better way to go and I want that setup as well.
How do I set up it, on my. domain I already have the dns set to my vps?
You'd have to move your tracking to a new subdomain, or host your landers on S3 on a new subdomain.
Barring some really complicated and inadvisable setup options, there's no way to have your tracker and your S3 landers on the same subdomain.
So you could have tracking on trk.domain.com and landers on www.domain.com , or you could have tracking on www.domain.com and landers on lp.domain.com
Does that make sense?
Originally Posted by caurmen
Yh it does makes sense and that was what I was implying with my question, but setting up the dns for trk.domain.com and domain.com kinda confused me. Anyway, in the guide you recommended using Route 53 with S3 I'm lost here. But
with S3 and Cloudflare I get a dns to add to my nameserver, wondering where Rout 53 comes in here.
If you're using Cloudflare you can set up the subdomains on there, AFAIK - no need to get Route 53 involved. That should work fine.
OMG. Thx u Lord finally I can setup AWS Cloudfront in S3 hosting with route 3 dns. I've been struggling for 2 days with no avail at last I got a ray of light
Hi caurmen,
Following your guide, I've finished setting up my domain on S3 + Cloudfront. However, there is one small problem that I really appreciate if you can help. My site seems to load perfectly at www.domain.com, but fail to load if I change the url to domain.com (without the www). Is there a way to make both url load the same html file?
Yep, there is - this is a bit of a pain on S3.
What you'll have to do is set up another bucket named domain.com , then in the settings tell it to redirect to www.domain.com .
You'll also need to set up another Cloudfront distribution for it.
Hope that helps!
Hi Caurmen,
A really great guide thank you! I've followed this tutorial to the step and the route53 one, but somehow I'm getting stuck at one point. The link provided at S3 and Cloudfont works perfectly, but whenever I try www.mydomain.com/index.html it doesn't work. The error I'm getting is ERR_EMPTY_RESPONSE.
I've been several times over the tutorial and I've read all comments, but none of the suggestions seem the work. I've set it up with S3, cloudfont and route53 and I've used namecheap for my domain. Exactly like the tutorial.
Do you have any idea where I went wrong? Or what steps I can take to figure this out?
Thank you!
Ah, that's annoying! Sympathy.
The good news is that a lot of the time that error can just mean your computer's lagging a bit behind on DNS updates.
First thing to try: try loading the domain from a computer that isn't your usual one. I'd recommend trying https://tools.pingdom.com/ and seeing if it loads your lander OK.
Let me know what the result is and we can go from there.
Damn, I was hoping for you this would be a simple fix!
No worries, we'll get this sorted.
OK, next things:
- What happens when you just go to www.mydomain.com?
- Try cutting Route53 out of the equation and just CNAME-ing the Cloudfront distro straight from Namecheap. Does that work?
- All DNS records are set up for www.domain.com, not domain.com?
If none of that works, post your Namecheap and Route53 setups here as images (feel free to obfuscate the cloudfront distro, but quadruple-check it for typos first!) and we'll dig in to see if there are any visible errors there.
1. You need to pick either having your nameservers on Namecheap set to the AWS ones or using Namecheap's DNS service -- you can't do both. Use the last screenshot with custom DNS and set to the 4 AWS nameservers.
2. Your nameservers in the 3rd screenshot in Namecheap all have periods after them. They should not, this can/will cause issues if a system does not strip them for you.
3. Likewise in other entries you seem to have these as well -- get rid of trailing periods. If you save without and the system adds them in (for some weird reason), so be it -- but don't put them in yourself.
4. You seem to have an A record in Route 53 set to an alias, which is a bit weird to me since an alias record is typically a CNAME, but whatever. I would make a new CNAME/alias record like "testing" and have that point to your cloudfront distribution domain, so you can quickly test resolution on a new subdomain that is not cached previously. You may need to correct your nameserver settings first though and wait, as I am not sure if these trailing periods are causing issues and if so how long it will take for them to resolve.
Hi, i amazon has changed a lot of related to this guide but all the names left the same so using the search i was able find the required sections without problems and get my example lp up !!!! WOW.
Maybe worth updating the guide.
Thanks for the guide, i would have never been coming to deal with cdn if it wasnt for this guide.
Those trailer periods were the issue. After changing them it's all good now. Thanks a lot!
I'll take a look at pt.4 soon.
how can i add a subdomain after having a domain working on amazon and cloudfront ?
@eradun - hmm, that's a bummer. I'll look into the new Amazon Way Of Doing Things once the eCommerce Cookbook is done.
Adding a subdomain: basically, go through the process again, but this time for the subdomain rather than the main domain. For all intents and purposes, subdomains are basically treated as new domains.
Of course, that assumes you want different content on the subdomain. If you want to use it for tracking or to redirect to your main domain, the process is a bit different - let me know if so and I'll explain.
Are you hosting your landing pages on
Otherwise, you'll need to have your Adsbridge tracking on a different domain or subdomain to your landers. So if your landers are on S3 at www.example.com you can't have Adsbridge running at www.example.com too - it'd have to be at anothersubdomain.example.com
Does that make sense?
Hi Caurmen,
No I'm not hosting at
Ah - for that you'll need to talk to
You could always register a different domain for your tracking!
You don't need to repeat the full process for this tutorial: just follow
I'm experiencing the following issue:
I got me S3 hosting, followed the tutorial, could also link my Namecheap domain BUT: Landers that I upload appear in Text Form with broken images everywhere. If I open them from my computer instead of the hosting, they appear normal though. Any thoughts on this?
Thanks
@nirvana - that's an great point, and thanks for raising it.
Do you (or anyone, feel free to suggest) have any suggestions on what would make it feel friendlier to non-techies? I agree, it's the least friendly part of the process by far!
Originally Posted by caurmen
If we are able to ease the readers mind with words such as anybody will get through this... the code you see below means nothing, it just has to be pasted.. etc.. then they are likely to be more optimistic with their own skill set.
The idea would be to make them realize that this is easier than it looks.
I look back at it now, its really simple steps that you cant mess up on unless you are going into sub domains etc.
Cheers
Great tip! I've added a paragraph to that effect.
Good advices. I registered with namecheap and Cloudflare, but after this tutorial i have switched to S3 + Cloudfront. Thank you for taking the time to write this post.
Yes, grant public read access. This may mean you don't need the bucket policy, but I tend to set it up anyway just in case 
Any reason why typing mydomain.com/index.html would the re-direct to mybucketname.s3.us-east-2.amazonaws.com/index.html?
It could be a timing reason? I noticed it initially did this for the first index.html page then I uploaded another one and the one works fine, but it is the outdate one, and the newer one index1 reverts to the bucket url location.
That would imply you've set your DNS up as a "URL Redirect" rather than a CNAME - or at least, that's the most obvious reason something like that would happen.
Is that the case? If not, we can dive deeper.
Hey caurmen,
thanks for the support on this.
I am very new to stm and am and would you recommend Amazon to start off temporary or would you us it full time ? I am thinking of using Bluehost but what are your thoughts on it.
Originally Posted by mangaoang2018
Does anyone know how to add SSL to their domain with this existing setup? I've read various tutorials online, but they're pretty extensive and I'm sure there has got to be an easier way. Has anyone done it yet?
Originally Posted by symba3
Originally Posted by symba3
Hello, I have added https with Certificate Manager and it works, but how to change URL in CloudFront so it would use that URL and not HTTP? I ran tests a few times and my URL with HTTP performs better than new https and I think it because https is not on cloudfront right?
How to enable SSL for the domain name?
Thanks for this great method! But I have forecasted usage is about 445% now (S3), it costs $4-5.
I use cloudfront but however it makes forecasted usage for S3, about 90k clicks at all.
So is it possible to decrease costs? Because I think that it's cheaper to have a vps if I'll get more clicks
Is there an updated version of this tutorial? s3 interface today looks totally different. Thank you
Originally Posted by i2raelgil
https://stmforum.com/forum/showthrea...osting-and-CDN
Home > Programming, Servers & Scripts >