Static IP for cloudfrontBlue/Green deployments with CloudFrontEC2 with AWS CloudFront?Can I hide S3 and...
Why would a jet engine that runs at temps excess of 2000°C burn when it crashes?
Does a Catoblepas statblock appear in an official D&D 5e product?
A question on the ultrafilter number
Can someone explain what is being said here in color publishing in the American Mathematical Monthly?
Does splitting a potentially monolithic application into several smaller ones help prevent bugs?
Unreachable code, but reachable with exception
Grey hair or white hair
Force user to remove USB token
Could you please stop shuffling the deck and play already?
Why does the negative sign arise in this thermodynamic relation?
Are the terms "stab" and "staccato" synonyms?
How do you like my writing?
Good for you! in Russian
Why is there a voltage between the mains ground and my radiator?
Should I tell my boss the work he did was worthless
Am I not good enough for you?
Finding algorithms of QGIS commands?
Is it true that real estate prices mainly go up?
What are the best books to study Neural Networks from a purely mathematical perspective?
Make a transparent 448*448 image
Peter's Strange Word
Examples of a statistic that is not independent of sample's distribution?
Making a sword in the stone, in a medieval world without magic
What is wrong with Escaped Shapeshifter's original wording?
Static IP for cloudfront
Blue/Green deployments with CloudFrontEC2 with AWS CloudFront?Can I hide S3 and Cloudfront endpoints?Amazon Cloudfront with S3 bucket - 2 originsAWS API Gateway Custom Domain: the domain you provided is already associated with an existing CloudFront distributionIs it possible to avoid costs for invalid requests at AWS S3 or cloudfront during a DDoS attack?Serve a static website on S3 via CloudFront and ACM SSL without Route53How do I limit S3 object access to CloudFront only?Cloudfront how to failover between multiple custom origins?Intermittent errors when loading static resources from AWS CloudFront
Is there any way to bind static IP to my cloudfront distribution?
I'm wondering if VPC can make that work.
I need static IP just to eliminate the problem of allowing in my firewall everytime AWS Cloudfront IP changes.
amazon-web-services amazon-vpc amazon-cloudfront
add a comment |
Is there any way to bind static IP to my cloudfront distribution?
I'm wondering if VPC can make that work.
I need static IP just to eliminate the problem of allowing in my firewall everytime AWS Cloudfront IP changes.
amazon-web-services amazon-vpc amazon-cloudfront
add a comment |
Is there any way to bind static IP to my cloudfront distribution?
I'm wondering if VPC can make that work.
I need static IP just to eliminate the problem of allowing in my firewall everytime AWS Cloudfront IP changes.
amazon-web-services amazon-vpc amazon-cloudfront
Is there any way to bind static IP to my cloudfront distribution?
I'm wondering if VPC can make that work.
I need static IP just to eliminate the problem of allowing in my firewall everytime AWS Cloudfront IP changes.
amazon-web-services amazon-vpc amazon-cloudfront
amazon-web-services amazon-vpc amazon-cloudfront
asked Jun 15 '14 at 13:11
droidlabourdroidlabour
6237
6237
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
"Your" Cloudfront distribution is not a single thing at a single place. It's a virtual entity on a global distributed network, and the more places from which it is being accessed, the more potential IP addresses you may see, because the requests are routed to the requester's nearest endpoint, using DNS. If I access your distribution, that's going to potentially involve a different IP address than if you access it, if we are in different places.
So, no, that isn't possible.
The list of possible addresses is, however, published...
https://forums.aws.amazon.com/ann.jspa?annID=2051
However, if you are referring to firewall rules allowing Cloudfront to access your origin server for security reasons, you have another flaw in your assumptions. There's no reason why multiple distributions couldn't use a common set of IP addresses... and, indeed they do... so it's conceivable that if you are trying to achieve some kind of security of your content using these restrictions, that a malicious user could provision their own distribution referencing your origin and access it via Cloudfront, if they knew how to access your origin server.
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html
There's a section in the Amazon CloudFront Developer Guide -- Using Custom Headers to Restrict Access to Your Content on a Custom Origin -- that describes one possible workaround: use a custom origin header with a secret value known only to CloudFront and your origin server. CloudFront injects these into the request, invisible to the browser. If this header and its secret value are not present in a request, then the request did not come to you through the CloudFront distribution, and can either be denied or perhaps redirected, by your origin server. This is also useful for ensuring proper parsing semantics for X-Forwarded-For
since its value for requests coming through CloudFront may require a different interpretation, particularly at an origin server behind a load balancer.
add a comment |
Yes, this is possible but that will cost you 600$ by month:
You need to set a custom domain and a custom SSL certificate to do that:
https://aws.amazon.com/cloudfront/custom-ssl-domains
1
Custom SSL gives you a dedicated IP at every edge location. However, as Michael points out, the solution to the problem in this question isn't a static IP, it's using AWS features as intended.
– Tim
Aug 29 '17 at 23:31
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "2"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f605263%2fstatic-ip-for-cloudfront%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
"Your" Cloudfront distribution is not a single thing at a single place. It's a virtual entity on a global distributed network, and the more places from which it is being accessed, the more potential IP addresses you may see, because the requests are routed to the requester's nearest endpoint, using DNS. If I access your distribution, that's going to potentially involve a different IP address than if you access it, if we are in different places.
So, no, that isn't possible.
The list of possible addresses is, however, published...
https://forums.aws.amazon.com/ann.jspa?annID=2051
However, if you are referring to firewall rules allowing Cloudfront to access your origin server for security reasons, you have another flaw in your assumptions. There's no reason why multiple distributions couldn't use a common set of IP addresses... and, indeed they do... so it's conceivable that if you are trying to achieve some kind of security of your content using these restrictions, that a malicious user could provision their own distribution referencing your origin and access it via Cloudfront, if they knew how to access your origin server.
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html
There's a section in the Amazon CloudFront Developer Guide -- Using Custom Headers to Restrict Access to Your Content on a Custom Origin -- that describes one possible workaround: use a custom origin header with a secret value known only to CloudFront and your origin server. CloudFront injects these into the request, invisible to the browser. If this header and its secret value are not present in a request, then the request did not come to you through the CloudFront distribution, and can either be denied or perhaps redirected, by your origin server. This is also useful for ensuring proper parsing semantics for X-Forwarded-For
since its value for requests coming through CloudFront may require a different interpretation, particularly at an origin server behind a load balancer.
add a comment |
"Your" Cloudfront distribution is not a single thing at a single place. It's a virtual entity on a global distributed network, and the more places from which it is being accessed, the more potential IP addresses you may see, because the requests are routed to the requester's nearest endpoint, using DNS. If I access your distribution, that's going to potentially involve a different IP address than if you access it, if we are in different places.
So, no, that isn't possible.
The list of possible addresses is, however, published...
https://forums.aws.amazon.com/ann.jspa?annID=2051
However, if you are referring to firewall rules allowing Cloudfront to access your origin server for security reasons, you have another flaw in your assumptions. There's no reason why multiple distributions couldn't use a common set of IP addresses... and, indeed they do... so it's conceivable that if you are trying to achieve some kind of security of your content using these restrictions, that a malicious user could provision their own distribution referencing your origin and access it via Cloudfront, if they knew how to access your origin server.
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html
There's a section in the Amazon CloudFront Developer Guide -- Using Custom Headers to Restrict Access to Your Content on a Custom Origin -- that describes one possible workaround: use a custom origin header with a secret value known only to CloudFront and your origin server. CloudFront injects these into the request, invisible to the browser. If this header and its secret value are not present in a request, then the request did not come to you through the CloudFront distribution, and can either be denied or perhaps redirected, by your origin server. This is also useful for ensuring proper parsing semantics for X-Forwarded-For
since its value for requests coming through CloudFront may require a different interpretation, particularly at an origin server behind a load balancer.
add a comment |
"Your" Cloudfront distribution is not a single thing at a single place. It's a virtual entity on a global distributed network, and the more places from which it is being accessed, the more potential IP addresses you may see, because the requests are routed to the requester's nearest endpoint, using DNS. If I access your distribution, that's going to potentially involve a different IP address than if you access it, if we are in different places.
So, no, that isn't possible.
The list of possible addresses is, however, published...
https://forums.aws.amazon.com/ann.jspa?annID=2051
However, if you are referring to firewall rules allowing Cloudfront to access your origin server for security reasons, you have another flaw in your assumptions. There's no reason why multiple distributions couldn't use a common set of IP addresses... and, indeed they do... so it's conceivable that if you are trying to achieve some kind of security of your content using these restrictions, that a malicious user could provision their own distribution referencing your origin and access it via Cloudfront, if they knew how to access your origin server.
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html
There's a section in the Amazon CloudFront Developer Guide -- Using Custom Headers to Restrict Access to Your Content on a Custom Origin -- that describes one possible workaround: use a custom origin header with a secret value known only to CloudFront and your origin server. CloudFront injects these into the request, invisible to the browser. If this header and its secret value are not present in a request, then the request did not come to you through the CloudFront distribution, and can either be denied or perhaps redirected, by your origin server. This is also useful for ensuring proper parsing semantics for X-Forwarded-For
since its value for requests coming through CloudFront may require a different interpretation, particularly at an origin server behind a load balancer.
"Your" Cloudfront distribution is not a single thing at a single place. It's a virtual entity on a global distributed network, and the more places from which it is being accessed, the more potential IP addresses you may see, because the requests are routed to the requester's nearest endpoint, using DNS. If I access your distribution, that's going to potentially involve a different IP address than if you access it, if we are in different places.
So, no, that isn't possible.
The list of possible addresses is, however, published...
https://forums.aws.amazon.com/ann.jspa?annID=2051
However, if you are referring to firewall rules allowing Cloudfront to access your origin server for security reasons, you have another flaw in your assumptions. There's no reason why multiple distributions couldn't use a common set of IP addresses... and, indeed they do... so it's conceivable that if you are trying to achieve some kind of security of your content using these restrictions, that a malicious user could provision their own distribution referencing your origin and access it via Cloudfront, if they knew how to access your origin server.
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html
There's a section in the Amazon CloudFront Developer Guide -- Using Custom Headers to Restrict Access to Your Content on a Custom Origin -- that describes one possible workaround: use a custom origin header with a secret value known only to CloudFront and your origin server. CloudFront injects these into the request, invisible to the browser. If this header and its secret value are not present in a request, then the request did not come to you through the CloudFront distribution, and can either be denied or perhaps redirected, by your origin server. This is also useful for ensuring proper parsing semantics for X-Forwarded-For
since its value for requests coming through CloudFront may require a different interpretation, particularly at an origin server behind a load balancer.
edited 9 mins ago
answered Jun 15 '14 at 16:21
Michael - sqlbotMichael - sqlbot
15.7k3058
15.7k3058
add a comment |
add a comment |
Yes, this is possible but that will cost you 600$ by month:
You need to set a custom domain and a custom SSL certificate to do that:
https://aws.amazon.com/cloudfront/custom-ssl-domains
1
Custom SSL gives you a dedicated IP at every edge location. However, as Michael points out, the solution to the problem in this question isn't a static IP, it's using AWS features as intended.
– Tim
Aug 29 '17 at 23:31
add a comment |
Yes, this is possible but that will cost you 600$ by month:
You need to set a custom domain and a custom SSL certificate to do that:
https://aws.amazon.com/cloudfront/custom-ssl-domains
1
Custom SSL gives you a dedicated IP at every edge location. However, as Michael points out, the solution to the problem in this question isn't a static IP, it's using AWS features as intended.
– Tim
Aug 29 '17 at 23:31
add a comment |
Yes, this is possible but that will cost you 600$ by month:
You need to set a custom domain and a custom SSL certificate to do that:
https://aws.amazon.com/cloudfront/custom-ssl-domains
Yes, this is possible but that will cost you 600$ by month:
You need to set a custom domain and a custom SSL certificate to do that:
https://aws.amazon.com/cloudfront/custom-ssl-domains
answered Aug 29 '17 at 23:06
xavierraffinxavierraffin
11
11
1
Custom SSL gives you a dedicated IP at every edge location. However, as Michael points out, the solution to the problem in this question isn't a static IP, it's using AWS features as intended.
– Tim
Aug 29 '17 at 23:31
add a comment |
1
Custom SSL gives you a dedicated IP at every edge location. However, as Michael points out, the solution to the problem in this question isn't a static IP, it's using AWS features as intended.
– Tim
Aug 29 '17 at 23:31
1
1
Custom SSL gives you a dedicated IP at every edge location. However, as Michael points out, the solution to the problem in this question isn't a static IP, it's using AWS features as intended.
– Tim
Aug 29 '17 at 23:31
Custom SSL gives you a dedicated IP at every edge location. However, as Michael points out, the solution to the problem in this question isn't a static IP, it's using AWS features as intended.
– Tim
Aug 29 '17 at 23:31
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f605263%2fstatic-ip-for-cloudfront%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown