Il binomio di servizi CloudFront – S3 fa oramai parte delle pratiche consolidate di molte aziende che hanno la necessità di ospitare un sito statico (o parte di esso) a prezzi contenuti senza rinunciare però ai crismi di sicurezza (come ad esempio la terminazione SSL sul proprio dominio). Ma è vero che è l’unica via percorribile? Esistono altri modi per conseguire il medesimo risultato che però rispondono ad esigenze differenti? In questo articolo si prova a dare una risposta!
Immaginiamo di dover rispondere alla seguente esigenza: il team di frontend della propria azienda richiede di poter testare ciò che ha appena sviluppato su un’infrastruttura simile a quella finale per mostrare anche solo a livello visivo che il risultato sia quello aspettato. In particolare, avrebbe piacere nell’avere a disposizione un nome di dominio differente per ogni feature in modo tale da non introdurre livelli di inconsistenza relativi ai path.
Anche senza prendere la calcolatrice in mano per fare i conti tentando di prevedere il traffico gestito, è subito chiaro che mantenere una differente distribuzione CloudFront per ogni feature e per ogni progetto frontend possa generare inutili complicazioni a livello di gestione dell’account AWS stesso. Vale la pena far notare che non è possibile creare due origin differenziate dalla path principale e collegarle a due domini differenti all’interno della stessa distribuzione CloudFront senza incorrere in almeno un redirect che porterebbe ai problemi di path sopra citati).
In prima istanza constatiamo la natura effimera di questi deploy. Ciò richiede che vi siano dei tempi relativamente ristretti di creazione e rimozione di questi elementi infrastrutturali. Per raggiungere questo obiettivo è utile quindi la condivisione delle medesime risorse da parte di più interlocutori in modo tale da minimizzare l’overhead introdotto.
La soluzione proposta è composta dai seguenti elementi infrastrutturali:
Per ottenere il risultato desiderato è fondamentale la creazione del Bucket S3 con la configurazione corretta. Di seguito la definizione in CloudFormation:
S3Bucket: Type: AWS::S3::Bucket Properties: BucketName: 'subdomain.mydomain.com' CorsConfiguration: CorsRules: - AllowedHeaders: - '*' AllowedMethods: - GET - HEAD - POST - PUT - DELETE AllowedOrigins: - 'https://*.mydomain.com' PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true WebsiteConfiguration: ErrorDocument: error.html IndexDocument: index.html S3BucketPolicy: Type: AWS::S3::BucketPolicy Properties: Bucket: !Ref S3Bucket PolicyDocument: Version: '2012-10-17' Statement: - Sid: VPCEndpointReadGetObject Effect: Allow Principal: "*" Action: s3:GetObject Resource: !Sub '${S3Bucket.Arn}/*' Condition: StringEquals: aws:sourceVpce: !Ref S3VPCEndpointId
Come si può notare, è stata attivata la “website configuration” in modo tale da poterci interfacciare con il bucket tramite chiamate HTTP ma allo stesso tempo è presente anche una Bucket Policy che vieta il recupero di un qualsiasi oggetto a meno che la richiesta non passi dal VPC Endpoint di S3, garantendo quindi che solo gli interlocutori che passano dalla VPC dell’account possano accedere al Bucket stesso.
Per permettere all’utente finale di visualizzare il sito statico ospitato su S3 occorre creare un Load Balancer (a seconda di chi possa essere questo utente finale, si può scegliere se rendere il Load Balancer privato o meno). In CloudFormation questo è l’insieme di risorse da creare:
LoadBalancer: Type: AWS::ElasticLoadBalancingV2::LoadBalancer Properties: Name: !Sub '${ProjectName}' LoadBalancerAttributes: - Key: 'idle_timeout.timeout_seconds' Value: '60' - Key: 'routing.http2.enabled' Value: 'true' - Key: 'access_logs.s3.enabled' Value: 'true' - Key: 'access_logs.s3.prefix' Value: loadbalancers - Key: 'access_logs.s3.bucket' Value: !Ref S3LogsBucketName Scheme: internet-facing SecurityGroups: - !Ref LoadBalancerSecurityGroup Subnets: - !Ref SubnetPublicAId - !Ref SubnetPublicBId - !Ref SubnetPublicCId Type: application LoadBalancerSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupName: !Sub '${ProjectName}-alb' GroupDescription: !Sub '${ProjectName} Load Balancer Security Group' SecurityGroupIngress: - CidrIp: 0.0.0.0/0 Description: ALB Ingress rule from world FromPort: 80 ToPort: 80 IpProtocol: tcp - CidrIp: 0.0.0.0/0 Description: ALB Ingress rule from world FromPort: 443 ToPort: 443 IpProtocol: tcp Tags: - Key: Name Value: !Sub '${ProjectName}-alb' - Key: Environment Value: !Ref Environment VpcId: !Ref VPCId HttpListener: Type: AWS::ElasticLoadBalancingV2::Listener Properties: DefaultActions: - RedirectConfig: Port: '443' Protocol: HTTPS StatusCode: 'HTTP_301' Type: redirect LoadBalancerArn: !Ref LoadBalancer Port: 80 Protocol: HTTP HttpsListener: Type: AWS::ElasticLoadBalancingV2::Listener Properties: Certificates: - CertificateArn: !Ref LoadBalancerCertificateArn DefaultActions: - Type: forward TargetGroupArn: !Ref TargetGroup LoadBalancerArn: !Ref LoadBalancer Port: 443 Protocol: HTTPS TargetGroup: Type: AWS::ElasticLoadBalancingV2::TargetGroup Properties: Name: !Sub '${ProjectName}' HealthCheckEnabled: false TargetType: lambda Targets: - Id: !GetAtt Lambda.Arn DependsOn: LambdaPermission
Tramite questo template, viene deployato un Load Balancer pubblico con un listener che ascolta sulla porta 80 (HTTP) che effettua una redirect su 443 (HTTPS) su cui è presente un altro listener che però contatta un Target Group su cui è registrata una Lambda.
La parte di logica della soluzione è demandata alla Lambda. Qui di seguito trovate un esempio di codice a titolo dimostrativo (a tal ragione si consiglia di rivederlo e adattarlo per soluzioni production-ready):
import json from boto3 import client as boto3_client from os import environ as os_environ import base64 from urllib3 import PoolManager http = PoolManager() s3 = boto3_client('s3') def handler(event, context): try: print(event) print(context) host = event['headers']['host'] print("Host:", host) feature = host.split('.')[0] feature = "-".join(feature.split('-')[1:]) print("Feature:", feature) path = event['path'] if event['path'] != "/" else "/index.html" print("Path:", path) query_string_parameters = event['queryStringParameters'] query_string_parameters = [f"{key}={value}" for key, value in event['queryStringParameters'].items()] print("Query String Parameters:", query_string_parameters) http_method = event["httpMethod"] url = f"http://{os_environ['S3_BUCKET']}.s3-website-eu-west-1.amazonaws.com/{feature}{path}{'?' if [] != query_string_parameters else ''}{'&'.join(query_string_parameters)}" print(url) headers = event['headers'] headers.pop("host") print("Headers:", headers) body = event['body'] print("Body:", body) r = http.request(http_method, url, headers=headers, body=body) print("Response:", r) print("Response Data:", r.data) try: decoded_response = base64.b64encode(r.data).decode('utf-8') except: decoded_response = base64.b64encode(r.data) print("Decoded Response:", decoded_response) print("Headers Response:", dict(r.headers)) return { 'statusCode': 200, 'body': decoded_response, "headers": dict(r.headers), "isBase64Encoded": True } except Exception as e: print(e) return { 'statusCode': 400 }
Nonostante non sia di immediata lettura, le operazioni effettuate sono molto semplici: partendo dal DNS name con cui l’utente ha raggiunto il Load Balancer, la Lambda gira la chiamata verso il Bucket S3 costruendo la sottocartella da contattare contenente una determinata feature. Per far si che tutto ciò funzioni bisogna chiaramente creare un DNS name per ciascuna feature.
Abbiamo visto come, grazie ad una opportuna configurazione delle risorse coinvolte, sia possibile mantenere un Bucket S3 privato nonostante il website hosting attivo, con lo scopo di avere una versione di un sito statico per ogni sottocartella definita, raggiungibile tramite differenti DNS name. Tale approccio è indubbiamente più veloce e agile quando le necessità sono legate alla verifica dell’aspetto visivo del sito e non della configurazione infrastrutturale, evitando quindi l’onere di tempo e di gestione di una distribuzione CloudFront.
Un buon risultato, vero? 🙂 Scriveteci per approfondire!