Posted on

AWS revenue jumps 49% in Q1/2018

 

The performance of the AWS remains strong. Already last year was excellent but the current year seems to accelerate the pace.  One year might be too short window to use but the picture is not so different with wider window. In two years the revenue has more than doubled from Q1/2016 and $2.566B to  $5.442B. From cash flow perspective, the impact of the AWS is crucial for Amazon. The quarter was good for Amazon (net income $1.9B in Q1) in particular due to the AWS as it generated net income of $1.4B alone.

It is worth to keep in mind that also other big public cloud vendors have increased their revenues a lot. Cloud market is bigger than ever and there are no indications that it will decrease any day soon. All of that underlines the trend that everyone is relying more and more on cloud based infrastructure. It is easy to point out the winners but where are the losers and how they can survive.  The only way to decrease the impact the is modifications to business models. Selling just capacity is not enough anymore and business models should leverage to new dimension, maybe content.

Amazon itself has studied new business innovations in retail industry a lot and one of the interesting one is Amazon Go.  That is a shop where are not clerks, customers just pick what they like and after they leave the shop they are automatically billed. For customer perspective that sounds fast, simple and convenient way to do shopping. Maybe that is the future…

-Tero

Posted on

Using S3 as a source action for CodePipeline

 

Rather new feature is to set S3 bucket to trigger CodePipeline (AWS blog).  There have been around scheduled pulls option for CodePipeline and S3 connection but since March 2018 also ‘push’ option is possible. There are good references available to set CodePipeline and that is therefore skipped in this blogpost. Lets run through a scenario where a new version arrives by Lambda. Let say the s3 bucket to be used is s3sourcebucket and the code is in the file.zip.

At first, versioning has to be turned on for S3 bucket. CodePipeline job can be identified by the version identifier. So after versioning turned on the S3 bucket is all set.

Then the focus is on CodePipeline. Lets use the CodePipeline console to configure the s3://s3sourcebucket/file.zip as the code source as (according to the documentation) CloudTrail and CloudWatch Events are automatically created and linked to the CodePipeline. Whenever new version is uploaded to the bucket, CloudTrail logs the API call, CloudWatch Event rule catch the CloudTrail logged trail and invokes the correspondent CodePipeline.

Below is an example of the automatically generated CloudWatch event rule. As default,  event pattern is built to match the entire event.

{
  "source": [ "aws.s3" ],
  "detail-type": [ "AWS API Call via CloudTrail" ],
  "detail": {
    "eventSource": [ "s3.amazonaws.com" ],
    "eventName": [ "PutObject" ],
    "resources": {
       "ARN": [ "arn:aws:s3:::s3sourcebucket/file.zip" ]
       }
    }
}

As the snippet points out, CloudWatch event rule is looking for “PutObject” as an EventName. That is the correct event name for ‘put’, as if IAM user is uploading a fresh file to the bucket. However, if the file transfers to the bucket by a copy operation, as if Lambda copies the file from somewhere to the bucket, then the EventName is not match. And the CodePipeline won-t be invoked. The correct event name is “CopyObject” for that occasion.  As a general hint for debugging, double-check the CloudTrail log for the correct event name and confirm that the same phrase is used in the CloudWatch Event rule.

-Tero

Posted on

Cloudfront for S3 website

S3 website is rather cheap serverless solution for delivering static websites such as single page applications. S3 architechture is regional and the website will face various latencies based on geographical location of the client. Latencies might vary from a few milliseconds to few hundreds. For some applications that might not be crucial but some other should utilize Content Delivery Network (CDN) to decrease latencies. CDN service in AWS is Cloudfront. Furthermore, S3 endpoint accepts only HTTP traffic from internet but with Cloudfront also HTTPS traffic is possible to be configured (between client and Cloudfront, but between Cloudfront and S3 bucket there is still HTTP).

Cloudfront is one of the global services in AWS that can be used to take the first hit and deliver the request further to dedicated region(s). Most likely due to the global approach the Cloudfront configuration has us-east-1 perspective. For example the custom SSL certificate should be requested for that region (through ACM) before those can be connected to the distribution. So even though the bucket is on any other region, the SSL certificate have to be requested to us-east-1.

Notes for distribution creation

It would be appealing to select the S3 Bucket as Origin Domain Name but that would not be correct (*). S3 Website is a custom origin and the Origin Domain Name should be the address of the S3 website (i.e. the word ‘s3-website’ should be there). Surprisingly, none of the s3-related options on the list is the correct one – they all point to S3 bucket not to the website… So copy-paste the s3-website address to the Origin Domain Name -field.

Due to the custom origin, Origin Access Identity cannot be used to control the access to the S3 bucket. And therefore -by default- any request can go directly to S3 website bypassing CloudFront. One way to confirm that S3 website is not accessible directly but only through Cloudfront is to define a Custom Header and set a long&random value for it. And update the bucket policy to deny all other requests. Below is an example bucket policy utilizing User-Agent as a custom header. Finally the CNAME should match to the S3 bucket name and then Route53 can be updated accordingly.

{
    "Version": "2012-10-17",
    "Id": "Policy15226007",
    "Statement": [
        {
            "Sid": "CFaccess",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": [
                "arn:aws:s3:::<bucket>/*",
                "arn:aws:s3:::<bucket>"
            ],
            "Condition": {
                "StringNotEquals": {
                    "aws:UserAgent": "fgrt45gfrt32hGGdsdeWEFgdd"
                }
            }
        }
    ]
}

 

(*) Cloudfront configuration is somewhat different when S3 bucket is not configured as a website. In this scenario, S3 bucket is just a place for SPA files. However, keeping S3 bucket as bucket (and selecting S3 as origin) requires that Cloudfront configuration includes:

a) default file (for example index.html) and

b) routing for Error(s), such as 403. The custom error pages are required as the requested file might not be there as it is SPA and errors should be handled by the SPA.  

-Tero