 Hello? May I audible? All right. So, the topic is perfecting the cloud recipe for an enterprise. So, this topic is pretty fresh just over the weekend we had implemented on a website for our retail investors, which pretty much leverages on CloudFront, S3, and Lambda Edge, and so far the response is pretty cool. This is perhaps a win-win solution to both the customers as well as SGX. So, for a customer to improve the usability a lot, whereas for SGX we can pretty much implement such a global solution with literally a very little effort. So, now let's get this started. So, a little about me, I'm Badri. I lead the digital infrastructure. I'm working in a Singapore Stock Exchange, and more importantly, I live and love Cloud. Here's the agenda for tonight. So, we'll begin with the motivation, what a motivator has to go to like such solution. We have a quick go-through on the AWS services what we have leveraged on, and I'll run through with the solution, which is pretty much a hybrid cloud implementation. I believe most of you comes from an enterprise. We will end up in having such solutions. You can pretty much relate to it. I'll explain you some of the design considerations, what we had done in implementing the solution, and then some of the operation considerations, which is very important as well, like a disaster recovery, and how do you manage deployments when there is no CI CD, and looking forward, what I'm expecting in this S3, Lambda Edge, and CloudTrend, we'll conclude at the questions. The motivation is very typical, I would say like we come from a traditional web server environment, where we host all of our single page applications, and there's an internet bandwidth constraints as well. So, we have a hard limit of 100 megabytes, that's very against scale. So, this internet bandwidth considerations, always also limits us to scale the number of concurrent users. So, let's assume for example, so we have 100 megabytes of internet bandwidth, and in a typical no good cat scenario, you can only scale up to 100 concurrent users, which is not the scale what we expect itself. And then obviously, we don't have any content delivery network. So, this all made us go with the natural choice. As an enterprise, we leverage on AWS public cloud as such for our implementations. And so, this introduces the natural choice with the AWS Lambda Edge, CloudTrend, and S3 in a pure serverless way, in hosting our single page applications. Cool. So, let's quickly go through on the AWS services, what is involved in this implementation itself. Holistically, there are two services, which are primarily two services, which are involved in this implementation, which is CloudTrend and S3. CloudTrend is basically a content delivery network, which you all have, which you all heard of. This content delivery network is basically a globally distributed network of proxy servers, which captures your content and accelerates your content delivery. What was interesting to me upon looking at the CloudTrend way of engineering is, so, they also optimize your TCP round trip. So, in all good scenario, this CloudTrend, it reduces the TCP round trip time by one RTT, which is very significant. And so, these are some of the SERP services, like Lambda Edge, Vaf, Shield, ACM. So, these are some of the services, which you implement separately, and you integrate with the CloudTrend to provide some comprehensive solution. So, Lambda Edge, which lets you run the code in the edge locations. So, if you think about it, so, this Lambda Edge, which lets you run the containers in all the pop locations. And if you look at the number of pop locations what we have in globally for AWS, it's quite a lot. And that sort of scale it provides with the Lambda Edge. And Vaf, it's a layer 75 wall. Shield, Shield is something which you don't implement separately, but it is something that's baked inside the CloudTrend, and it's guides you against the layer three and layer four DDoS attacks. And ACM, this is the place where you upload your customer service certificate, which is pretty much the case with all the enterprise itself. So, and together with all the services, you integrate with the CloudTrend, which provides the comprehensive solution. And then the origin, for us, the origin, it's, we pretty much leverage on S3, which is our storage, you know, where we store over all the front-end assets. And KMS, we are pretty much for data encryption at rest. So, whatever the logs we deposit, we come from financial services where we're very sensitive to any data at rest. So, this KMS, which we manage our keys to encrypt the data at rest, you know, for the data we deposit in the S3 itself. Cool. So, let me run through, quickly run through the solution. And I believe we pretty much correlate with the solution against your enterprise itself. So, there are two components, DNS and Vaf, which are managed in the enterprise. Other than that, we are on the CloudTrend and S3, which is managed in the AWS public cloud. So, DNS, we pretty much hosted an on-premise, which runs in the traditional data center. And Vaf, which is a managed service provider, it is a cloud-based provider, which purely does the Vaf. So, if you run through the solution, user issues, the DNS queries, let's say, so-and-so, SGX.com, it results to the Vaf IP, the Vaf public IP address. This Vaf public IP address, it records, it scrubs the request payload. It does all the layers of stuff, all the layers of its scrubbing. And it forwards the request to the CloudTrend pop. So, before forwarding the request to the CloudTrend pop, it resolves the distribution with the CloudTrend pop IP based on a lot of parameters, like the network congestion and the catch availability, the server capacity, quite a lot of metrics to determine your CloudTrend pop IP. And the Vaf forwards the request to the pop. So, once Vaf determines the request for the CloudTrend pop IP itself, it forwards the request to the CloudTrend. Whereas the CloudTrend, it doesn't begin with serve the request. All it does is, it does the SNI validation. How many of you are familiar of SNI validation? Right, so, CloudTrend, when you create a distribution, it carries its own SSL certificate for CloudTrend.net, yeah? So, but then we enterprise, we come with a custom domain. So, for us, it's SGX.com. So, we also apply an SSL certificate for SGX.com, so-and-so.SGX.com. So, how the CloudTrend differentiates which SSL certificate you present toward the request we're just coming in. All it does is, it performs the host validation with the server header on the layer 4 and it presents the certificate back for the custom domain, what you're presenting itself. In this case, so-and-so.SGX.com. And then, CloudTrend evaluates the Vaf ACL rules, the access control, access control list rules. This Vaf, which evaluates the rule, which whitelists the public IP address, what it comes from the, you know, what is managed in the enterprise itself. Once it whitelists, CloudTrend evaluates the path pattern, what you're defining it. So, each and every request what is getting triggered back to the CloudTrend, it comes to the set and relative path itself. So, in a CloudTrend, here you can define a behaviors and with the respect, and you can try the behavior with the respective origin, in our case, it's S3. So, it evaluates the path and forwards the request to the respective, you know, S3 origin itself. So, the S3, what it does is, we store objects which are private, which we discuss later. So, this S3, it evaluates the bucket policy and it authenticates the request which is coming from the CloudTrend and it presents back the object. So, when S3 presents back the object, we don't directly present back to the user. We invoke lambda at edge on the origin response. So, upon receiving an origin response from S3, this S3 response gets decorated by the lambda edge and this response is decorated and presents back to the CloudTrend catch. And then CloudTrend, it retries the catch response and present back to the user. Right, now let's go through the design considerations, right. So, we are pretty sure that we are gonna use this S3 for storing our single page, you know, front and the sets itself. Now, there comes a differentiation like whether we use S3 origin or S3 website. S3 website is typically in a, you can treat like a web server, right. So, S3 website is more of like, it's the HTTP integration to your CloudTrend itself. Whereas S3 origin, it's more of like a REST API endpoint, which formulates the standard according to the AWS S3 RESTful standards and it triggers the request itself. So, we had quite a lot of factors which we had evaluated at the time of selecting wish to go with and these are some of the four significant factors which, you know, which we, which decide our solution itself, which is pretty much an access control. With S3 origin, you can host both the public and the private objects. There's a website, it only supports the public objects. Customer response, with S3 origin, it returns back some XML formatted response. Whereas S3 website is more of like the web server kind of utility for any customer response code, like say, 404, HTTP 404, HTTP 500. It presents back the index, in the presence back the HTML page, what you predefined in each of the response code itself. And then the redirects in support, S3 origin obviously is more of like a REST API endpoint, it doesn't, it's not applicable. And S3 websites, it supports both object and the bucket level redirects. SSL support, yes, S3 origin comes with it supports the SSL connection, whereas the website doesn't support SSL, it's only so through HTTP. So if you look at the difference, right, the key difference is between the security and the usability. What do you think we have selected? Yeah, exactly. Security eats the strategy for breakfast, right? So we had to go with the S3 origin. So on S3 origin, there are two things which you tie with the, which you consider in S3 origin itself. One is the origin access identity, another one is the data at rest. Origin access identity is typically, we treat that like a special user, yeah? So you create the special user and you try that to the CloudTrend origin. So here in this case, we create this user and we associate that with the CloudTrend origin. When the request gets initiated from the CloudTrend origin and it presents it back to S3, it authenticates the request with the identity what you indicate itself. And then S3 evaluates against the bucket policy and it ensures this origin access identity is authorized to read the object itself. So there are a few pointers to consider. So create the, don't reuse the, don't reuse the origin access identity for different origins. Create a separate origin access identity and tie that with each of the origins for your integration itself. If not, you're potentially reusing the same security bucket policies where this user will pretty much have access to a different origin that it is not supposed to. And then data address, yes. We, CloudTrend does captures all the access logs. We feel some, you know, we are very sensitive, security sensitive organization that we make sure like, you know, all this data address, like even the client IP address needs to be encrypted. So we don't use SS, you know, S3, SSC, what it defaults comes with. We create a customer vanish key with a KMS and they tie that back with the object, tie that back the objects for our data encryption address. Right, so there's something which you need to consider for the catch behaviors at all. So then, okay, so first avoid adding the catch headers. Avoid adding the catch headers in the origin, you know, as much as possible. So what, perhaps what I'm trying to say here is, you define your catch definitions at the CloudTrend level and manage this catch responsibility at one place, don't manage two places. So as long as you feel that individual objects in S3 needs a separate catch definitions, then it makes sense. You can add those catch headers in the S3 objects and they can advise the CloudTrend to respect to the catch header definitions, what you define in the individual objects itself. Which is typically not the case for most of the use cases. So as long as it is not needed, trap, you know, have the catch header definitions defined only in the CloudTrend version, which is easy for you to manage itself. And compress the data, yeah. Compress the data to thin the data transfer to internet and also it improves the page performance, right? So with CloudTrend, you pay for the number of requests and you pay for the data transfer out to the internet. So before serving the response back to the internet, compress your response. Compress your response and press it back whereas the browser naturally has the ability to decode the ZZ compression in extracting your files itself. And one other consideration, so there's only one custom error response you can have in your CloudTrend distribution. What does it mean? So in a CloudTrend distribution, you can have multiple origins. So let's say here in our case, we have two S3 buckets with two different code bases. So these two different code bases carries a separate, you know, custom error response index pages, HTML pages. But irrespective of it, we are limited with only one custom error response, what we can implement in the CloudTrend itself. So that introduces the necessity of having a Lambda IDH at the time when we present back a response to make, we evaluate the request pattern and if this request pattern matches so-and-so code bases, we present back the origin response from the respect to S3 bucket accordingly. Right, so, and then WAF. So on a WAF, what we basically do is, so we white list, we white list the enterprise managed WAF public IP address to be only authenticated to receive the request from the CloudTrend. And on top of it, we also make sure we white list some of the synthetic monitoring public IP address. So this is pretty much needed for you to differentiate, for you to isolate where the issue is coming from. In an event of any issues, you want to isolate whether it is from a WAF, which is managed by an enterprise, or it is from the CloudTrend itself. So white list the IP, white list the IP where it's necessary for you to, you know, troubleshoot the issues as well. Otherwise proceed with the explicit deny. So ACM, ACM is the place where we upload our customer service certificate and we tie that back to the CloudTrend. And there's one important thing, right? So during this implementation, I had come across an article for CloudTrend domain hijacking, which was pretty scary. So always associate a scene with the CloudTrend distribution. So just to give you a bit of context of what is this CloudTrend domain hijacking itself, right? So when you create a CloudTrend distribution, it comes with a unique distribution name. So this unique distribution name, which is pretty much a C name for your DNS. Yeah, so, but what a CloudTrend internally does is, when you initiate a request, CloudTrend directly doesn't forward the request to the distribution. It evaluates whether the request host header matches the C name what you define in this CloudTrend distribution. If it doesn't match, the request will fail. And at the same time, if someone else have the C name defined, irrespective of whatever the distribution you map to this DNS, and if someone else have defined the C name with their own distribution, your request will forward to that distribution, which is very scary. There's a recent development where they have tightened the security policies in uploading the SSL identities in providing the authenticity to defining the C name into the CloudTrend itself. Again, that is not comprehensive. So this is something which is expected to, this is something which is open and is expected to fix. So always associate a C name with the CloudTrend distribution, and when it's not needed, make sure you clean up your DNS here. Right, so Lambda Edge. So Lambda Edge is pretty much a necessity for us, right? There are a few things. So there's only so much content headers, so much response headers, you can define an S3 object. So when you present back a response, we expect some of the security headers, like X-Frame options, XSS protection, content security policies, all the security headers, which is not available in S3 right now. And you don't have any means in defining the content headers other than to inject the Lambda Edge itself. So we had to inject this Lambda Edge upon presenting the origin response from S3 to order all the security headers and to present back the response itself. And also one other thing, like I'm not sure, you followed the announcement of S3 select with the recent reinventer. So this S3 select, it pretty much improves the compute time in retrieving the response from the bucket itself. So it does pretty cool operations on the data at rest in S3, not on the network level. So whatever the queries you are executing, it pretty much execute on the data at rest, which solves a lot of computers in time, as well as it solves the data transfer time. All right, so cloud trial. So these are some of the operation considerations we had to do. So what is the cloud trial? Right, and now we have the service implemented. How do we monitor, like how do we monitor who is uploading the data into buckets, right? So we need to have a telemetry to see, like who is updating the content. In a way that this ensures the data integrity itself. So what we basically do is we integrate all the S3 write events along with the cloud trial. So we monitor the events which are interest, which is basically a put object. So any object you write in S3, it triggers a put object call. So we monitor this event. It is always coming up from the associated user. So what are the authorized user? If we feel something suspicious, it triggers an alert. So always integrate the cloud trial events along with the S3 write minimally. So and monitor the suspicious API calls in the cloud trial alarm itself. And then AWS cloud watch. So cloud friend by default comes to the pretty cool dashboard. And but that is not sufficient for you to create an alarm itself. So you have to integrate, pretty much integrate whatever the default metrics which is available in the cloud friend with the cloud watch. So there are a few things of which you can monitor this more of like, the error response codes and the surgeon request. So do remember that you pay for the number of requests and the byte which is transferred back to the internet. So if you feel anomaly in the surgeon request, you can always trigger an alarm with the cloud watch itself. And yeah, lambda. So perhaps for our production enrollment, we don't have a CD yet. We're in a progress in progress of implementation. So but then I'm not a big fan of implementing and a long-term access keys in the long-term access keys in IMXS keys for the deployment itself. So how do you solve this problem, right? So we pretty much leverage on lambda. So this lambda, all it does is it assumes the role which produces back the temporary security credentials, which is basically an access key, security access key and the session token. So this session token all it valid for about one app. And then when you execute again, it relates back. So with the key credentials, we integrate with our deployment procedures to present back to for the deployment execution itself. And you're sure that after one hour, the keys expire, right? So as an enterprise, we always care about disaster recovery. So here, disaster recovery, it's not about availability. It's about other contingency events. For instance, like more of like, what happens if the account itself is compromised, right? So you pretty much need to have a procedure. It is very important for us to document whatever you have done. In this case, basically, whatever the cloud formation templates, what we have used to create this infrastructure. So in an event of any contingency, you pretty much follow this documentation and execute the CF templates which replicates the infrastructure itself. Cool. So this is something I'm looking forward. How many of you are aware of broadly? Oh, yes, Steve, always. So actually, broadly is pretty cool. So broadly is an advanced compression standard. So for any typical web request, we pretty much follow a Zizip. Whereas broadly, it is an advanced compression. It is pretty much like in a 30 percentage efficient than Zizip. So which means when you enable a broccoli, you reduce the data by another 30 percentage and you improve the page load performance and also improve the data transfer back to the internet, right? So there are a few challenges right now. Broadly is not supported across all the browsers. So that means you pretty much need to validate this request agents, user agents, and to present back the broadly response accordingly. And yeah, so I'm led to micro-pages strategy. So we have a different code base now and which is managed by a different team of people itself. So going forward, what we are trying to embrace is leveraging on the micro-pages strategy itself. So with the different code bases, you have a different S3 origins and different S3 origin for each of the pages what you define, which can carry with its own pipeline to have that implemented itself. And all you manage is the routers in the lambda edge which forwards the request to the respective S3 origin. Depends on the page request itself. Yeah, so the cloud trial, which we are pretty much working on creating a wrapper layer for all of our communication channel integration so to deliver the alerts to Slack for any instant communication channel itself. So that concludes my presentation. Q&A. Sorry? You mentioned there is some secure data in S3, right? Yeah, yeah. What do you mean? Actually, in a way, not all of it. Whatever the SPE, the web pages we present is more of an anonymous data. We should don't care about it. But whereas the more of an access logs, so whatever the access logs, it pretty much captures the client IP address. So where the request is getting originated from. So, well, again, so you can still don't need, you still don't have to implement this KMS or the data address on the S3 itself. But we, from a security sensitive organization, we make sure like, you know, whatever the sensitive information what we feel, we encrypt the data at rest. Static? Yes, it is a static website, yes, yes. It's more of the access logs we encrypt, yeah. And it's with the web components, yeah. HTML5 web components, yep. So if there are no further questions, then we'll conclude now.