Choosing a Deployment Path
AWS offers several distinct ways to get an application running, and picking the right one depends mostly on how much infrastructure control you want versus how much you'd rather AWS manage for you. Raw EC2 instances give full control over the operating system but require you to handle patching, scaling, and deployment yourself. Elastic Beanstalk sits a level up, managing the underlying EC2 instances, load balancer, and Auto Scaling group for you while still exposing the servers if you need to tweak them. Further up the abstraction ladder, ECS/Fargate runs containers without managing servers at all, Lambda plus API Gateway runs individual functions with no servers to think about, and AWS Amplify is purpose-built for deploying static or JAMstack frontends straight from a Git repository.
Cricket analogy: It's like the choice between a groundstaff-prepared pitch (raw EC2, you control every detail) versus a franchise-provided turf wicket (Elastic Beanstalk, mostly managed but still tweakable) for a T20 league match.
Deploying with Elastic Beanstalk
Elastic Beanstalk deployment starts with eb init, which associates your local project with an Elastic Beanstalk application and lets you pick a platform (Node.js, Python, Java, Docker, and more). Running eb create provisions the environment — EC2 instances, a security group, an Auto Scaling group, and optionally a load balancer — from scratch, while subsequent eb deploy commands zip your code and roll it out to the existing environment using a rolling or all-at-once deployment strategy. Beanstalk continuously monitors instance health and can automatically replace unhealthy instances, and the whole environment can be customized further with .ebextensions configuration files checked into your repository.
Cricket analogy: eb init is like a team registering for a league and selecting its playing format (T20 vs ODI), while eb create is like the ground being built out with pitch, stands, and floodlights ready for the first match.
# Elastic Beanstalk deployment workflow
eb init my-flask-app --platform python-3.12 --region us-east-1
eb create my-flask-app-prod --instance-type t3.small --envvars FLASK_ENV=production
# After making code changes:
eb deploy
# Check environment health and recent events
eb status
eb healthDeploying a Static Site with S3 and CloudFront
For a static site — plain HTML/CSS/JS or a built React/Vue app — the simplest production-grade path is an S3 bucket configured for static website hosting, sitting behind a CloudFront distribution for HTTPS, caching, and global edge delivery. You upload the built files to the bucket, point CloudFront's origin at the bucket (ideally using an Origin Access Control so the bucket itself stays private), and attach an ACM certificate plus a Route 53 alias record so the site resolves under your own domain with HTTPS by default rather than the raw S3 website endpoint.
Cricket analogy: The S3 bucket is like a stadium's central archive of match footage, and CloudFront is like regional broadcast affiliates that cache and rebroadcast that footage locally so fans in each city get low-latency coverage.
CI/CD Basics
Manually running eb deploy or uploading files to S3 works for a first deployment, but a repeatable pipeline is what makes deployments safe and boring. AWS CodePipeline can orchestrate the full flow: CodeBuild compiles and tests the application from a source stage (often CodeCommit, GitHub, or S3), and CodeDeploy or a Beanstalk deploy action pushes the built artifact to the target environment. Many teams today instead use GitHub Actions with OpenID Connect (OIDC) federation to assume an IAM role directly, avoiding long-lived AWS access keys stored as repository secrets — the workflow authenticates just-in-time for each deployment run.
Cricket analogy: A CI/CD pipeline is like a franchise's standardized selection-to-playing-XI process — scouting, trials, training camp, then match day — replacing an ad hoc 'pick whoever's available' approach with a repeatable, reliable system.
For a first project, deploying manually with eb deploy or aws s3 sync is perfectly fine while you're learning — introduce CI/CD once the deployment steps stop changing and you want them to run the same way every time without manual intervention.
A common beginner mistake is making an S3 bucket 'public' to serve a website directly, which exposes the bucket to the internet and is easy to misconfigure into a data leak. Prefer keeping the bucket private and routing all public traffic through CloudFront with an Origin Access Control, which serves content without ever making the bucket itself publicly accessible.
- Deployment options range from full control (raw EC2) to fully managed (Elastic Beanstalk, ECS/Fargate, Lambda, Amplify).
- Elastic Beanstalk provisions EC2, load balancing, and Auto Scaling automatically via eb init/eb create, then eb deploy pushes code updates.
- Static sites are best served from a private S3 bucket behind CloudFront, not directly via S3's public website endpoint.
- Route 53 plus an ACM certificate lets a CloudFront distribution serve HTTPS traffic under your own custom domain.
- CI/CD pipelines (CodePipeline/CodeBuild/CodeDeploy or GitHub Actions) make deployments repeatable instead of manual and error-prone.
- GitHub Actions with OIDC federation avoids storing long-lived AWS access keys as repository secrets.
- Public S3 buckets are a common misconfiguration risk; CloudFront with Origin Access Control keeps the bucket private.
Practice what you learned
1. Which Elastic Beanstalk CLI command provisions the underlying EC2 instances and load balancer for the first time?
2. What is the recommended way to serve a static website from S3 in production?
3. What is the main security benefit of using GitHub Actions OIDC federation instead of static AWS access keys?
4. Which AWS service is purpose-built for deploying static or JAMstack frontends directly from a Git repository?
Was this page helpful?
You May Also Like
CloudWatch Monitoring Basics
Learn how Amazon CloudWatch collects metrics and logs from your AWS resources, and how to build alarms that alert you before small issues become outages.
The AWS Well-Architected Framework
A structured overview of the six pillars AWS uses to evaluate cloud architectures, and the practical trade-offs engineers face applying them.
AWS Quick Reference
A condensed cheat sheet of core AWS compute, storage, networking, database, IAM, and CLI facts for fast lookup and last-minute review.