CloudNuro.AI is a next-generation SaaS company focused on bringing artificial intelligence and machine learning to SaaS operations and management, optimizing SaaS spend, improving security and compliance, developing SaaS insight, and maximizing ROI for SaaS investment. CloudNuro offers a central point from where, apart from discovering the growing stack of SaaS applications, software administrators can manage application access for users/teams, licensing and spending, IT workflows, integration, data and access security, SaaS related process automation and policy compliance. CloudNuro is used by companies to realize the following benefits: 1. Discover their growing SaaS application stack for greater control and visibility over their SaaS portfolios 2. Track utilization, manage costs and eliminate wastage in the form of unused user license for SaaS applications. 3. Automate provisioning and de-provisioning of users for added security and process compliance 4. Centrally manage SaaS licenses and renewals 5. Uncover "Shadow IT" Applications (Use of SaaS systems/services without explicit IT department approval) 6. Ensure transparency and accountability of SaaS application usage across all employees We've partnered with Google (GCP) to provide enterprise-grade cloud solutions and Cloud Security Alliance (CSA) to help ensure to bring the best practices for a secure cloud computing environment for all our customers.

CloudNuro

is one of the most popular CMSs. It’s easy to install and easy to use, and there are thousands of plugins and templates that make the website development super easy and super fast. But its advantages are also disadvantages because the page generation can be really resource-demanding and WordPress is not only one of the most popular but also one of the most vulnerable systems. WordPress There are many cases where a simple static webpage would be enough, but using WordPress is a more convenient solution.  A blog or a product website is a good example. You have to simply choose a template, set the colors and some other things, upload the content, and voila, you have a full-featured website with some hours of work. These are the cases when CloudFront can be a good solution to make your website fast, scalable, and secure. is a . A worldwide distributed cache system. When a user tries to access your content through CloudFront, the system routes the request to the nearest edge server which serves the content if it exists on it or asks it from your WordPress server. Amazon CloudFront Content Delivery Network In this case, WordPress is something like a static page generator that generates the pages that CloudFront serves. The resource consumption of your site will be extremely low because CloudFront asks for the content only once and serves it million times if needed. You can handle extremely high traffic with millions of users by using only a micro instance for your WordPress! Another advantage of this system is that only the CloudFront part is public. Your WordPress is hidden from the outer world so, nobody can attack or hack it. Behind CloudFront, your origin is in maximum safety. To add CloudFront to your WordPress site, set up a CloudFront distribution on the AWS console. Set the origin domain to your current WordPress site URL, and give a name to your distribution. On the “Settings” block choose an alternate domain. This will be the new domain where your WordPress site will be accessible through CloudFront. If the deployment is done, copy the CloudFront domain name, and create a CNAME record to it. For example, if your alternate domain is and the CloudFront domain is , then add a www.example.com d3qu6ceheilwux.cloudfront.net www.example.com CNAME d3qu6ceheilwux.cloudfront.net record to your DNS zone file. If everything has done well, you will see your site on . Clicking on the links on the new site will go back to the original WordPress site. To prevent this, add these two lines of code to the beginning of your wp-config.php: www.example.com if($_SERVER['HTTP_USER_AGENT'] == 'Amazon CloudFront') {
    define( 'WP_HOME', '... new site URL …' );
    define( 'WP_SITEURL', '... new site URL …' );
} else {
    define( 'WP_HOME', '... original site URL …' );
    define( 'WP_SITEURL', '... original site URL …' );
} The user agent of CloudFront is ‘Amazon CloudFront’, so when CloudFront reads the site content, it will get the new URLs, but when we access it for the administration, it will use the original URLs. After this modification, the links will point to the CloudFront URLs (ex.: ). www.example.com Congratulation! You have set up CloudFront for your WordPress site. We are almost done, but I promised improved safety and our original site is still public. The easiest way to prevent attacks on the original site is to add HTTP authentication with a strong password to it. If you are using Nginx, you can generate a password file by using the htpasswd utility: htpasswd -c /etc/nginx/htpasswd wordpress that you can add to your config: auth_basic           "Password protected content";
auth_basic_user_file /etc/nginx/htpasswd; CloudFront can send HTTP headers when it accesses the origin, so you can add the auth header to its config. The auth header looks like this: Authorization: Basic {base64encode({user}:{password})} So, if your user name is abc and your password is 123 then the auth header will be: Authorization: Basic YWJjOjEyMw== The header can be generated by using any . If you generated the header, add it to your origin’s config. online base64 encoder After the deployment, CloudFront will access your site, so it will be publically available through CloudFront, but the original site will be password protected. To keep your site protected, you can change the password monthly and set up to prevent brute force attacks. fail2ban The last thing that I wanted to talk about is invalidation. The default behavior of CloudFront is that it refreshes the content only once per day, so if you change something and don’t want to wait for a day, you have to delete the cache. CloudFront uses invalidations to do it. If you want to delete one or more files from the cache, you have to create an invalidation. Invalidation is a broadcast message to the edge servers to delete the given content. The parameter of the invalidation is a list of file paths that can contain * If you want to fully delete the cache, use ‘/*’. . As you see, CloudFront is a perfect solution to scale your WordPress site and make it safe. By using it, your site can serve millions of users, and you need only a micro instance behind CloudFront. The solution is not WordPress specific. You can use it for any site that does not use server-side interactions. In some cases, it needs a little bit of different thinking. For example, you have to use hosted comment services like Disqus or Facebook comments, or if you have a webshop on your site, you have to organize it to another domain as a separate service. But I think it's a really low price for the safety and the seamless, fast, and scalable content serving.

How to Make Your WordPress Site Safe and Fast With Amazon Cloudfront

How Amazon CloudFront Secures Content Delivery

CloudFront is AWS own CDN (Content Delivery Network). CDNs are primarily used for caching, and many customers also use AWS CloudFront CDN as a security layer, or use it to handle network spikes. With AWS CloudFront CDN, when a user requests a webpage or an image, the request is routed to one of Amazon’s locations. If the edge server already has the resource cached, it’s served to the client. If the resource isn’t on the edge server, it makes a request to a larger edge server called a regional edge cache, if it’s not there, the request arrives at an origin server that houses your application. The edge server then saves a copy of the response locally so it can handle the next request without pestering the origin server. This reduces load on the origin server, helping you keep the instance housing your application small, and is able to reduce latency for clients by moving commonly requested resources closer to the requestor. This is great for your latency, and user experience, but how does it impact your costs? 225+ edge server This guide will walk you through the following: AWS CloudFront pricing Factors that determine Amazon CloudFront cost Ways to Reduce CloudFront Cost AWS CloudFront Pricing AWS CloudFront pricing starts with a very simple pricing model, you’re charged per GB transferred to the internet and for every HTTP request. There are also lots of optional features, like encryption, logging, Origin Shield, file invalidation, and edge server Lambda invocations that can also . incur additional CloudFront costs CloudFront Cost & AWS Data Transfer Cost The AWS CloudFront cost is billed per GB transferred from any CloudFront edge server out to the internet. Once you start transferring more than 40TB of data, you are charged less per GB, and the cost continues to decrease the more data you transfer until you hit 5PB. Like most AWS services, these costs vary by region. The initial rate for the serving data to the cheapest regions (United States, Mexico, Canada, Europe and Israel) is $0.085 per GB, and this cost doubles to $0.170 when serving data to the most expensive region (India). You’re also charged for requests that send data to your origin application, like WebSocket connections, or data attached to PUT requests from a client. Because CloudFront is intrinsically global, the region you’re billed for isn’t determined by where your application lives, but by where the requests to your application originate. You can manage these costs by setting a on your CloudFront distribution that excludes certain regions from your edge server network. price class You can get an Amazon CloudFront pricing discount by committing to a regular level of use (typically at least 10TB transferred per month for a year long commitment period). Unlike many other services, these CloudFront “Reserved Instance” prices are not published, but if your organization can reasonably commit to transferring that data over a long time period, it could reduce your costs, so and ask. You can also get a 30% discount by signing up for the . You have to commit to spending a specific amount on CloudFront services every month for a least a year, and it’s a great deal if you’re also considering utilizing the Amazon (WAF) because 10% of your commitment value is generated as WAF credit. contact AWS CloudFront Security Savings Bundle Web Application Firewall CloudFront Request Costs Another factor of AWS CloudFront pricing is being charged per 10,000 HTTP requests, and you’ll pay a premium of about 25% to handle HTTPS requests. These CloudFront costs also vary based on the region the request originated in, but the pricing difference is less dramatic than for data transfer, dropping from a 100% premium for data transfer to the most expensive regions to a 10% premium for handling requests from these areas. Other CloudFront Costs is an additional caching layer that operates (and is priced based on) the availability zone of your origin server. All requests to your origin server go through this single caching layer, so users accessing different edge servers in different locations can be served the same cached content, and applications operating multiple CDNs have access to a unifying caching layer. This service is charged at the same rate as HTTP requests, adding to the cost of any request that makes it past an edge server. CloudFront also allows you to so only applications that have access to the decryption key are able to see sensitive data. This service costs $0.02 for every 10,000 requests that are encrypted (in addition to the HTTPS request costs). You have the option of generating and monitoring at a cost of $0.01 for every 1,000,000 log lines written. Finally, you can provide custom for your CloudFront distributions for $600 per month. Origin Shield encrypt specific fields real time logs SSL certificates and domain name How to reduce AWS CloudFront Costs Now, with the understanding of Amazon CloudFront pricing and the many cost factors that contribute to its usage, there are several practical and common methods to reduce CloudFront costs. In the following, we’ll cover ways to reduce S3 and EC2 costs with CloudFront, the best way to configure CloudFront, and how to increase your cache hit ratio to trim costs. Reducing AWS S3 and EC2 Costs With CloudFront One of the most common uses of CloudFront is delivering web and content stored in an S3 bucket or EC2 instance to clients all over the world. At low data volumes, the cost of using S3 is actually cheaper because every month you get the first GB transferred out free, but as soon as you start to increase your usage, the cheaper per GB cost of serving data from CloudFront kicks in. In a cheap region like US East Ohio, that inflection point is 18 GB. media Once the amount of data transferred out to the internet increases, the pricing gap for data transfer costs starts to widen. Once you start transferring terabytes of data, the distance between serving content from an origin like S3 and using CloudFront to deliver content opens up dramatically. It’s important to realize that CloudFront has a special status in the AWS universe. Normally, you’re charged for data transferred between availability zones. However, data transferred from AWS services to CloudFront servers doesn’t cost a cent. If you’re transferring a very small amount of data out to the internet, it’s cheaper to not use CloudFront, but if you’re transferring data between zones, or are dealing with larger data transfer costs, CloudFront is almost always going to save money. This special status also makes it cost effective to always pair CloudFront with hosting your origin server on the AWS network. If you self host your origin server, or use a different provider, those data transfer savings vanish, and you have to pay to transfer data into CloudFront, which means anytime an item is not in the cache, you’re paying twice, once to transfer data to the CDN, then again to transfer the data to the client. Comparing the cost of handling HTTP requests between S3 and CloudFront is less straightforward. If your application is exclusively serving GET results, handling requests out of an S3 bucket is significantly cheaper. In US East Ohio, you’ll pay $0.004 per 10,000 requests made directly against an S3 bucket, but you’ll pay at least $0.0075 to serve requests from CloudFront, making it almost 90% more expensive. This calculation is flipped once you start mixing in POST requests. The price doesn’t change based on request type for CloudFront, but it shoots up by more than 100% for S3 buckets, you’ll pay $0.05 to serve up 10,000 POST requests, so CloudFront becomes the better deal, offering an 85% discount on these types of requests. For most applications, data transfer costs and savings on instance size will significantly overshadow the cost of serving requests, so this difference is rarely significant, but if a large portion of the costs for your CloudFront application are caused by many requests for small files, and you can guarantee those requests will primarily be GETs, then consider skipping CloudFront. On the subject of requests, you should also evaluate how necessary using HTTPS is for your application. Handling HTTPS requests adds about 25% to request costs, so if you’re not receiving sensitive data, using plain HTTP can save you a chunk of change. Configuring Amazon CloudFront to Reduce Costs One of the best ways to reduce requests to any web server is by caching content on the client’s browser. This basic idea applies twice when using CloudFront, because CloudFront adds a second layer of caching, files are also cached on edge servers. By default, all files served by CloudFront’s edge server expire after 24 hours, which is far too low for many types of content. You can increase the value of your CloudFront network by appropriately caching objects, particularly ones that you are confident will not change for a while. You can set how long both the client and edge server caches objects by setting the Cache-Control HTTP header at your origin server. You can also instruct your edge servers to implement their own caching policy by setting when you create or update your CloudFront distribution. Be aware that edge server caching is important to plan and implement carefully because if you want to invalidate files before they expire, you can invalidate 1,000 paths for free each month but you’ll pay $0.005 after that limit. Time To Live (TTL) values per path invalidated Increasing Your AWS CloudFront’s Cache Hit Ratio A primary goal of the CloudFront CDN is to avoid inundating your origin server by allowing edge servers to efficiently respond to client requests. This functionality is undermined if most clients end up requesting content that isn’t cached. The ratio of requests that are handled by the edge server compared to the number of requests that arrive at the origin server is called the cache hit ratio. You can increase this ratio by understanding how the works. When a resource is requested by a client, CloudFront generates a cache key (by default, this uses the domain of the distribution and the path of the requested object, but you can then store the cache key and use it to serve future matching requests. To increase the hit percentage, consolidate application views to resolve to a single cache key and avoid adding data that might cause two requests with the same results to generate different cache keys, like creating two URLs that point at the same resource. cache key modify those settings Compression to Reduce Amazon CloudFront Cost CloudFront can be configured to some kinds of files. CloudFront compression will result in a faster load time for clients, and will decrease your costs as edge servers transfer smaller amounts of data to clients. In addition to using default compression, compress resources as they are generated by your origin server. automatically compress AWS CloudFront Free Tier The CloudFront free tier is one of the most generous in the AWS family, you get 50 GB of data transfer out and two million requests every month for a year. If you aren’t already using CloudFront, the free tier can help you decide if it can help you downsize the instance serving your application or dramatically improve client experience by decreasing their load time. Conclusion Amazon CloudFront CDN makes serving resources from a globally distributed CDN simple. This can reduce latency, handle spikes in demand, and decrease the load on your application servers. Leveraging good caching policies, compression, and understanding how the cache key works allows CloudFront to perform these tasks effectively, which helps you get the most value from the service. First published here

A Guide to Paying Less For AWS CloudFront

The demand for video is growing, and even more, businesses find infinite possibilities in this sector. We’re not just referring to entertainment or instructional materials here. Content providers, small businesses, and corporate brands are all benefiting from video on demand. Brands can build stronger relationships with their customers by offering them access to the information they want, whenever and however they want it. Thus, such visualization became the most convenient way to share data with software users. VOD (video on demand) refers to any content delivery method that allows users to select when, where, and how they interact with media integration. This can be accomplished by either simultaneous broadcasting from an internet source or by the user downloading the video to a personal device for subsequent viewing. This is in contrast to traditional streaming, when the viewer may only see their film on a gadget with a satellite or cable connection at a certain period. VOD Streaming has a wide range of applications in the business sector. It may be used to make money, connect with people, and more. Although creating video content necessitates a substantial amount of time and work, many experts believe that the investment is worthwhile. VOD streaming data and trends show how valuable this API integration is, for example, the statistics demonstrate, that the websites featuring video content keep visitors on the site for a longer period of time. This factor influences the engagement of the user with the content, and in particular with the VOD streaming – increasing the chances to convert a lead into a client. Why VOD Delivery on AWS? By using AWS Cloud, Amazon Web Services (AWS) offers two media integration solutions for delivering VOD content to worldwide viewers. The Video on Demand on Amazon Web Services solutions provides the resources needed for API integration of sustainable, decentralized VOD transportation and management processes. This solution makes , which decomposes the workflow into individual phases, making it easy to adapt or expand the architecture to meet your unique video-on-demand requirements. use of Amazon Web Services This method reaches multiple functional advantages: Transcode videos uploaded to S3 into formats that can be played on a variety of devices automatically. Upload individual files for each input to customize MediaConvert job settings. Store transcoded files in a destination bucket and send them to end-users through Amazon CloudFront. The AWS solution for Video on Demand may be readily modified and used as a starting point for more sophisticated workflows. The VOD on AWS solution, on the other hand, makes use of AWS Step Functions, which break down the workflow into individual phases, making it easy to adapt or expand the architecture to meet your unique video-on-demand requirements. Getting Started This guide will show you how to set up and configure different API integration services to upload, transcode, and deliver video on demand to your users. First of all, we need to plan the content storage and processing pipeline. It would be a great solution to implement video uploading on serverless architecture. The choice was made by the peculiarity of video content transferring. It could easily cause traffic overhead on any server, and balancing systems in most cases are too slow to react to them quickly enough. It is the reason we use to accept media integration, store it on , and trigger processing with service. AWS Lambda an S3 bucket AWS Elemental MediaConvert Here is the diagram of the system we going to build: What you’ll need Amazon Web Services account Python 3.8 Git 2.0 or newer]( ) https://cdn.hackernoon.com/images/xWx1eln9Ida9r216TnPyHFrKw1J2-fu037xo.png 1. Create User and Storage for Videos Create AWS User First, we need to create an AWS user and buckets for files. To create the user you should follow the following instructions: Sign in to the Amazon Web Services Management Console and open the IAM console. Select Users from the navigation pane, then Add Users. Select the Programmatic access as a type of access. For permissions choose S3, MediaConvert, Lambda, Cloudfront, IAM, CloudWatch Events, and CloudFormation. For tags, you could add whatever you want to categorize the user by. Copy and . We’ll need them later for Lambda to access resources. Access key ID Secret access key Create S3 buckets The workflow we planned to implement needs 2 buckets: one to store videos downloaded by customers, and the other one to store transcoded videos and distribute them to users. So you have to follow the instruction below twice. Go to Amazon Web Services S3 dashboard. Press Create bucket button and type the bucket’s name. Then choose the default region for your account and don’t forget to check the “Block all public access” checkbox, otherwise, there would be security issues in the system. Leave other options as is and press Create bucket button Buckets should be created in the same account within the same region. 2. Create CloudFront Distribution for Videos We need the distribution to provide videos to users all over the world. To create one, please, follow the instructions: Visit the AWS CloudFront and press the button to create a CloudFront distribution home page As the origin, choose the output S3 bucket created in prev step For bucket access, choose to and then for the distribution. Also, don’t forget to hit the button. use OAI Create a new OAI update bucket policy Then, leave other options as default till you come to the section where you should choose option. Viewer Redirect HTTP to HTTPS Below the menu, you could set up an alternate CNAME and choose a certificate for your domain. This allows you to provide your URL to end-users. Then click the button and store the distribution’s id. Create distribution 3. Create Lambda function Then we need to create and deploy an API with 1 endpoint to upload videos. In the future, we could extend the functionality of the system to allow managing uploaded videos. We suggest using the Flask application with the Zappa package to set up and deploy the app on AWS Lambda. Flask is a lightweight and easy-to-use Python framework that fits our goals extremely well. As one option you could clone (by command git clone) the sample app here. In the next step, you need to configure the app to work with your infrastructure. In the configs folder, there is an file which should be populated with AWS IAM user’s credentials, input/output buckets, and CloudFront distribution id you’ve created early in this guide. app_config.json Next, install modules for Python. You could do this by following the instructions below: Create a virtual environment by using the command: python3 -m venv venv Activate the env: source venv/bin/activate Install packages pip install -r requirements.txt Add IAM user’s credentials to the file ~/.aws/credentials under video_uploader tag. It should look like this: Our next step is to set up Zappa to deploy the code on Amazon Web Services lambda. Type the command: Zappa init Choose the environment name and video_uploader profile Then, choose any bucket you want to upload code (it could be the default) and leave the modular path as is Press y to confirm settings After the setup, you could type to deploy the code to lambda. When the command is finished, you will get a URL to upload your videos to. You could test the functionality by executing this sample cURL: Zappa deploy dev curl --location --request POST '{your_api_url}/upload_video' \
--form 'video=@"{full_path_to_video}"' Replace your_api_url with the URL you got after Zappa deploy and full_path_to_video with a path to the video you want to upload. Summary VOD streaming is extremely useful in a variety of sectors and for a variety of purposes. Viewers may enjoy accessible media anytime and wherever they choose using VOD. Users get great material while also getting the convenience they want via . VOD streaming The nice thing about streaming and video on demand is that they’re not mutually exclusive: you can benefit the most from combining the two. You may use live broadcasts to connect with viewers and establish relationships, and VOD to reuse previously recorded content. All of this while lowering expenses and increasing service. By including live stream sessions in your video-on-demand library, viewers will have . They may watch available material whenever and wherever they choose thanks to a video on demand. Your target audience gets memorable online experiences as well as the convenience and performance that they expect. access to your content 24/7 The system is resistant to loads and simple to use. There are a lot of ways to improve such kind of API integration. But the most important will be the authorization functionality and the video managing panel. First published on here

Build a Video On Demand (VOD) Service with AWS Lambda, S3 and CloudFront

Comparing Cloudinary CDN and Amazon AWS CDN CloudFront 

I recently worked on implementing CloudFront for s3 bucket files. Most of the tutorials were doing that using console management(UI) but we at prefer “code as infrastructure”. So I had to do this using CloudFormation. With the help of a few StackOverflow links and tutorials, I was able to write CloudFormation Template. Blue Sky Analytics So What exactly CloudFront and CloudFromation are? These definitions will help you out. CloudFront: Amazon CloudFront is a fast content delivery network (CDN) service that securely delivers data, videos, applications, and APIs to customers globally with low latency, high transfer speeds, all within a developer-friendly environment. CloudFromation: On AWS, the CloudFormation service provides Infrastructure as Code capabilities. CloudFormation uses , configuration files defined in JSON or YAML syntax, that are human readable and can be easily edited, which you can use to define the resources you want to set up. CloudFormation reads a template and generates a , a set of resources ready to use on AWS. templates stack How is this gonna work? We are gonna use a private bucket, a public bucket can also be used but we don't use it to avoid direct access to bucket and leakage. CloudFront can access private bucket data using OAI(Origin Access Identity). An OAI is like a virtual user through which CloudFront can access private bucket. After creating OAI and using it in CloudFront, we need to update bucket policy, So that CloudFront with an OAI can access it. Resources we are going to build using CloudFormation: S3 Bucket OAI(Origin Access Identity). Update Bucket Policy CloudFront Distribution AWSTemplateFormatVersion: "2010-09-09" Resources: First, we need to define AWS template version and a "Resources" attribute to start writing resource templates. AWS template version defines the capabilities of a template. S3 Bucket Bucker resource template Bucket:
        Type: AWS::S3::Bucket
        Properties:
            AccessControl: Private
            BucketName: private-bucket
            Tags:
                - Key: description
                  Value: "Private files" "Bucket" is the name of resource template. We can use it any suitable name here. "Type" defines the type of resource, after this, we can define properties of resource. Each resource will have its own properties. OAI(Origin Access Identity) OAI resource template CloudFrontOriginIdentity:
    Type: AWS::CloudFront::CloudFrontOriginAccessIdentity
    Properties:
      CloudFrontOriginAccessIdentityConfig:
        Comment: 'origin identity' Update Bucket Policy Template resource to update bucket policy. BucketPolicy: Type: AWS::S3::BucketPolicy Properties: Bucket: private-bucket PolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: AWS: !Sub 'arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity ${CloudFrontOriginIdentity}' Action: 's3:GetObject' Resource: arn:aws:s3:::private-bucket/* Two of the most important fields, here are AWS field under principle and Resource fields. Recently created OAI can be used directly by using its template resource name like this "${CloudFrontOriginIdentity}" CloudFront Distribution Now the final CloudFront Distribution resource template. One property you need to be careful here is "Origins", that basically defines your bucket origin and "DomainName"  will be like this "${bucket name}.s3.${region}.amazonaws.com". publicDistribution: Type: AWS::CloudFront::Distribution Properties: DistributionConfig: Origins: - DomainName: private-bucket.s3.us-east-2.amazonaws.com Id: S3-private-bucket S3OriginConfig: OriginAccessIdentity: !Sub 'origin-access-identity/cloudfront/${CloudFrontOriginIdentity}' Enabled: 'true' Comment: Some comment DefaultCacheBehavior: AllowedMethods: - GET - HEAD TargetOriginId: S3-private-bucket ForwardedValues: QueryString: 'false' Cookies: Forward: none ViewerProtocolPolicy: redirect-to-https ViewerCertificate: CloudFrontDefaultCertificate: 'true' After completing CloudFromation template, you can use sam command to deploy and check status of its CloudFromation stack. Sam command : sam deploy --template-file [sample-template] --stack-name [Stack name] --s3-bucket sam-test-bucket --capabilities CAPABILITY_IAM Few links to learn more: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-distribution.html https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-cloudfront.html Thanks for reading 💓️

How To Configure CloudFront Using CloudFormation Template

Cómo configurar CloudFront usando la plantilla de CloudFormation

What is CloudFront? CloudFront is a CDN (Content Delivery Network). The CloudFront retrieves data from the Amazon S3 bucket and distributes it to multiple datacenter locations. The data that delivers through a network of data centers is called edge locations. The nearest edge location is routed when the user requests for data, so we will get some benefits like the lowest latency, low network traffic, fast access to data, etc. A picture will help you to clarify how this actually works, so take a look at the image shown below. We have stored our content or data in an S3 bucket located in a region in N.Virginia(us-east-1), and we have users located around the world who access that content. As the arrows show, whenever a user requests content, the request must go over the public internet to the source location–the S3 bucket in N.Virginia(us-east-1). Depending on the user’s location, content delivery can take a long time. The delays in the response or in content delivery might even cause some user requests to bounce and return an error from the page. Now imagine that we set up CloudFront in front of the S3 bucket. In the following image, you can see that there are no longer requests traversing the globe to get to our content. Instead, requests are routed to the ones that are closest in terms of delivery speed. These are also called “least latent” Edge Location. As shown with the green arrows, CloudFront then quickly serves cached content directly to the requesting user nearby. CloudFront retrieves the content from the S3 bucket origin if it is not cached with an edge server. Instead of the public internet, the content traverses the AWS private network and CloudFront optimizes the TCP handshake. Hence, the request and content return are still much faster than access across the public internet. So by using CloudFront will fetch data from CloudFront data centers instead of S3. The following Image is showing us the same thing. Let’s start the creation of CloudFront distribution. 1. Steps for creating a CloudFront distribution Sign in to the AWS Management Console and in the you can see a search box in that type cloud and choose . Find Services, CloudFront You should for the region at the top right. Global Click . Create Distribution Under click . Web Get Started For once you place the cursor in there you should see your available S3 buckets. Origin Domain Name Note: I already created S3 bucket in AWS so If you don’t have any website on S3 bucket then plz create it first Pick the website bucket you created. If it’s not listed type it in: e.g 2020–05–21-mybucket.s3.amazonaws.com  that is nothing but your bucket name. Leave blank. Origin Path The should have been pre-populated when you choose your bucket. Origin ID Click to . Yes Restrict Bucket Access Under select . Origin Access Identity Create a New Identity It will pre-populate the and append the bucket name. Comment For on Bucket choose options . [This will update the bucket policy for us]. Grant Read Permissions Update Bucket Policy Leave the blank. Origin Custom Headers For the section: Default Cache Behavior Settings Under select option . Viewer Protocol Policy Redirect HTTP to HTTPS For choose . Allowed HTTP Methods GET, HEAD Leave blank. Field-level Encryption Config Leave for . GET, HEAD (Cached by default) Cached HTTP Methods For leave it as the defaul Cache Based on Selected Request Headers t none (Improves Caching). For also leave it as the default . Object Caching Use Origin Cache Headers Under leave it as . Forward Cookies None (Improves Caching) Also for leave as Query String Forwarding and Caching None (Improves Caching). For select . Smoothing streaming No For select . Restrict Viewer Access (Use Signed URLs or Signed Cookies) No Leave as . Compress Objects Automatically No Leave as the default. Lambda Function Associations Scroll down to . Distribution Settings For leave the default . Price Class Use All Edge Locations (Best Performance) We will not be using WAF, so for leave it as . AWS WAF Web ACL, None Leave blank. Alternate Domain Names (CNAMEs) We will also use the for Default CloudFront Certificate SSL Certificate. For leave as . Supported HTTP Versions HTTP/2,HTTP/1.1,HTTP/1.0 Under type . Default Root Object index.html We can leave set to . Logging Off Leave checked. Enable IPv6 Finally set the to . Distribution State Enabled Click . Create Distribution Click on at the top left to see the status of CloudFront distribution being built or not. Distributions This can take 15–20 minutes to complete. 2. Restrict our S3 bucket policy to Cloud Front Click at the top left and type in S3 or select it from History. Services Click on your Bucket name . 2019-mm-dd-xx-mybucket IMPORTANT: Your bucket will have a different name. Click . Permissions Select . Bucket Policy We can see that CloudFront has added what we call an “Origin Access Identity” to the policy. {
"Version": " – – ",
"Statement": [
{
"Sid": "AddPerm",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3::: – – -mybucket/*"
},
{
"Sid": " ",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E2V8GJ8FKJPGFQ"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3::: – – -mybucket/*"
}
]
} 2012 10 17 2020 05 21 2 2020 05 21 Remove the public s3 section so it looks like following {
"Version": " – – ",
"Statement": [
{
"Sid": " ",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E2V8GJ8FKJPGFQ"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3::: – – -mybucket/*"
}
]
} 2012 10 17 2 2020 05 21 This will only allow our specific CloudFront distribution access to our S3 bucket which is what we want. Click Save. 3. Steps for testing that we successfully locked down S3 from public view Browse to your S3 endpoint: Example: http://2020-05-21-mybucket.s3-website-us-east-1.amazonaws.com You will see a because we removed public access from the bucket policy. 403 Forbidden Click on the . (The blue hyperlink) CloudFront distribution ID Copy the URL under . Domain Name Browse to that URL and you should now see the index.html page. And your CloudFront is ready. Happy Coding 😃

Creating an Amazon CloudFront Distribution [A Step-by-Step Guide]

When developing an application it is important to have assets resized for different capabilities, screen sizes, and resolutions. This is important for many reasons. Low resolution images on high resolution displays make a bad UX High resolution images on low resolution displays waste both and device and server bandwidth resources Creating several thumbnails during image upload, can be a and for future redesigns. lot of work limits the agility Adopting an image in-app and it may be heavy for the app especially if you use Frameworks. cropping/resizing Resizing on the fly Instead of processing and resizing images into all necessary sizes upon upload, the approach of processing images on the fly has several upsides: Increased agility Reduced storage costs Resilience to failure In this post, we’ll be using a different approach and outline a method of lazily generating images, in which a resized asset is only created if a user requests that specific size. Creating a new bucket Open s3 console You can or use existing one but make sure the bucket’s read access permission is set to public. create new bucket Create new bucket, uncheck Block all public access Go to tab then choose permissions bucket policy To grant read-only permission to an anonymous user. Copy and paste this configuration to your bucket policy. Make sure to replace with the name of the bucket. You can read about bucket policy more in YOUR_BUCKET_NAME_HERE here { : , : [
        { : , : , : , : , : }
    ]
} "Version" "2012-10-17" "Statement" "Sid" "PublicRead" "Effect" "Allow" "Principal" "*" "Action" "s3:GetObject" "Resource" "arn:aws:s3:::YOUR_BUCKET_NAME_HERE/*" 6. Choose save Go to properties tab Choose static web hosting Choose use this bucket to host a website For , enter index.html index document Choose save. We’ll come later and add but for now just leave it empty. redirection rule Note the website’s endpoint* Creating CloudFront distribution for SSL Open CloudFront console Choose create distribution Choose web distribution Enter the that was noted previously, for static website’s endpoint origin domain name For viewer protocol policy — choose Redirect HTTP to HTTPS For object chaching set and TTL to 0 and TTL to 31536000 choose customize minimum default maximum Rest of the configuration you can leave as it is. You can now choose create distribution This can take few mins, wait until the status changes from ‘in progress’ to ‘deployed’. After the status is changed to deployed, note the CloudFront domain name. It should look similar to blabla .cloudfront.net Setting up permission for Lambda function Open IAM console Creating policy: In the IAM console select from the dashboard to the left Policies Choose create policy Navigate to tab JSON Replace with the name of the bucket that you’ve created and copy the following code into the policy document. Note that any leading spaces in your policy may cause a validation error. YOUR_BUCKET_NAME_HERE { : , : [
        { : , : [ , , ], : },
        { : , : , : }
    ]
} "Version" "2012-10-17" "Statement" "Effect" "Allow" "Action" "logs:CreateLogGroup" "logs:CreateLogStream" "logs:PutLogEvents" "Resource" "arn:aws:logs:*:*:*" "Effect" "Allow" "Action" "s3:PutObject" "Resource" "arn:aws:s3:::__YOUR_BUCKET_NAME_HERE__/*" Choose review policy Enter your policy name You can use any name but just for simplicity we’ll use the name imageResizePolicy Create policy Creating role: In the IAM console select from the dashboard to the left Roles Select create role Choose in for a use case, Lamda next In permission section search for the that you just created and choose that, You can skip the tags section and choose imageResizePolicy next Next In review section, enter role name, you can use any name but for the sake of simplicity we’ll be using the name imageResizeRole Create role Creating Lambda function Open Lambda console In the lambda console choose create function For function name enter your function name, now of course you can choose any name for just to be safe use as your function name. So that it’ll be easy for you to follow along. imageResize Choose as a runtime. Again you can choose any other language but we’re going to choose Node. You don’t need to worry about it as this lamba function works completely independent from your application. The only purpose it’ll serve is to provide you with resized images on fly. Node.js 12.x Expand the permission dropdown and select . use existing role Select imageResizeRole Choose create function Now choose and select from the dropdown add trigger API Gateway For choose API type HTTP API To allow all users to invoke the API method, for , choose and then . Security Open Add Now back to the main function window, you’ll see section. function code For code entry type choose upload a zip file Download function.zip file from this and upload the zip file, from top right corner link choose save To configure your function environment variables add two variables: For key, and enter for value, enter the bucket name that you created above. BUCKET; For key, enter ; for enter the domain the you created above from CloudFront, similar to URL value blabla.cloudfront.net On the main function window, choose API gateway and scroll a bit till you see our function’s API endpoint. Note the full path of the endpoint, depending upon your personal configuration these might be slightly different. Setting up S3 redirection rule Ok we’re almost there, phew that was a lot of configurations. In s3 console, open the bucket that you created above. To to properties and expand static website hosting, edit redirection rules. Replace (similar to ) with the hostname that you noted above and copy the following into redirection rules configuration. YOUR_API_HOSTNAME_HERE blabla.execute-api.us-east-1.amazonaws.com Notice the path inside <ReplaceKeyPrefixWith> tag, it’s the same from the one we noted above in picture. If your path is different the update it with your path. <RoutingRules>
  <RoutingRule>
    <Condition>
      <KeyPrefixEquals/>
      <HttpErrorCodeReturnedEquals> </HttpErrorCodeReturnedEquals>
    </Condition>
    <Redirect>
      <Protocol>https</Protocol>
      <HostName>__YOUR_API_HOSTNAME_HERE</HostName>
      <ReplaceKeyPrefixWith>default/imageResize?key=</ReplaceKeyPrefixWith>
      <HttpRedirectCode> </HttpRedirectCode>
    </Redirect>
  </RoutingRule>
</RoutingRules> 404 307 Test image resizing Upload a test image into your bucket to for testing. Once uploaded, try to retrieve resized versions of the image using your CloudFront domain: https://YOUR_CLOUDFRONT_DOMAIN/300×300/{image_name.jpg} https://YOUR_CLOUDFRONT_DOMAIN/25×25/{image_name.jpg} https://YOUR_CLOUDFRONT_DOMAIN/500×500/{image_name.jpg} You should see a smaller version of the test photo. If not, choose Monitoring in your Lambda function and check CloudWatch Logs for troubleshooting. You can also refer to the GitHub repo for a working example that you can deploy to your account. serverless-image-resizing YOU MADE IT!!! 🚀🎉🎊 Previously published at https://medium.com/@lamamanjil/image-resize-on-fly-with-amazon-s3-aws-lambda-and-cloudfront-for-ssl-8ab046ccf79f

CLOUDNURO

cloudnuro.ai

11-50 employees

Since 2021

COMPANY RANKING

CLOUDNURO

EVERGREEN INDEX #2794

Representing this company? Click here to claim and customize this page!

CloudNuro WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

CLOUDNURO

cloudnuro.ai

11-50 employees

Since 2021

COMPANY RANKING

CLOUDNURO

EVERGREEN INDEX #2794

RELATED COMPANIESRANK

STORIES ABOUT CLOUDNURO

Representing this company? Click here to claim and customize this page!

CloudNuro WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!