Certification Progress

Currently preparing for the AWS Certified Solutions Architect Associate exam (planned for December 2025).

✍️ Entry #009 – SES Domain Setup successful & Approval links active

📅 2025-08-11

Summary SES domain a-grognards-journey-to-the-cloud.com is verified, and Easy DKIM is enabled. Lambda 1 (ReceiveCVRequest) is live in SES sandbox, sending auto-replies and owner notifications with signed approval/deny links. The CSV audit log is written to the same S3 bucket as the CV.

What I did - Created SES domain identity and enabled Easy DKIM (3 CNAMEs added in Route 53). - Verified owner email for sandbox testing. - Updated Lambda 1 env vars (bucket, object key, approval base URL, secret, etc.). - Sent a live test: received owner email with approve/deny links.

Current status - SES Identity: Verified - DKIM: Enabled - SES mode: Sandbox (send to verified recipients only)

Next steps 1. Build the /approve Lambda (Approval Handler): - Verify HMAC token & expiry - On approve: generate presigned S3 URL and email it to requester (SES) - On deny: send polite rejection email - Append action to CSV log in S3 2. Request SES Production Access to email unverified recipients. 3. Run a full end-to-end test outside sandbox. 4. (Optional) Add CloudFront + custom domain + HTTPS if not already in place.

✍️ Entry #008 – S3 Website nearing launch

📅 2025-08-10

Today’s checkpoint on the S3 Static Website project feels like the eve before deployment.
Most components are in place:

• S3 Static Website: fully hosted and serving content through CloudFront.
• Custom Domain: a-grognards-journey-to-the-cloud.com wired up via Route 53 and secured with ACM.
• Content & Layout: HTML, CSS, images – including personal and deployments sections – all online.

What’s left?
Only the Presigned URL delivery mechanism remains to be completed. Once that’s in place, access requests will be handled securely, approvals issued, and download links sent automatically.

Once this final piece locks in, the site will be ready to go live — the grognard’s journey will officially march into the cloud battlefield.

✍️ Entry – Amazon VPC Essentials

📅 2025-08-06

Theoretical insights:
Today I explored the fundamentals of Amazon Virtual Private Cloud (VPC). VPCs allow you to define your own isolated network within AWS, giving full control over IP ranges, subnets, route tables, gateways, and network access policies.

I learned the differences between the Default VPC and a Custom VPC: - The Default VPC comes preconfigured with a /16 CIDR, public subnets, IGW, and DNS support. - A Custom VPC is built from scratch and enables more secure, scalable, and production-ready architectures.

Additionally, I reviewed the concept of tenancy: - default → EC2 instances run on shared hardware. - dedicated → Instances run on physically isolated hardware, often for compliance reasons.If dedicated is used during VPC setup, it is inherited for the underlying architecture as well.

Networking key takeaways: - VPC CIDR must be between /28 and /16. - Optional IPv6 /56 block is public by default and needs proper route/security config. - DNS within a VPC depends on enableDnsSupport and enableDnsHostnames. - Public subnets require an IGW; private subnets use a NAT Gateway for outbound traffic.

Security layers: - Security Groups are stateful and apply at the ENI level. - Network ACLs (NACLs) are stateless, work at the subnet level, and support deny rules.

This foundational knowledge is critical for both exam success and real-world AWS networking design.

Keywords: custom vpc, default vpc, cidr, nat gateway, dns, tenancy, security group, nacl

✍️ Entry #006 – Working on S3 Static Website

📅 2025-08-05

Mission Overview:
The goal is to build a secure, request-driven CV delivery system, using a combination of:

• Static website hosted on S3 for user interaction
• API Gateway + Lambda for controlled request intake
• SNS + approval logic to manually authorize access
• Presigned URLs to deliver the CV temporarily and securely
• CloudFront to enable HTTPS access and fast global delivery

💡 Concept Summary:
1. The S3 static website shows a CV request form.
2. When a user submits the form, a Lambda behind API Gateway processes the request and notifies the owner via SNS.
3. Upon manual approval, another Lambda generates a Presigned S3 URL, which is returned to the user (or sent via email).
4. CloudFront serves the entire website securely via HTTPS – this includes the form and later the presigned download endpoint.

✅ Component Status (as of today):

• [x] S3 Static Website configured
• [x] Lambda function for CV request active
• [x] API Gateway integrated and CORS-compliant
• [x] SNS notifications delivered successfully
• [ ] Approval logic with Presigned URL pending
• [ ] Presigned URL Lambda not implemented yet
• [x] CloudFront distribution created
• [ ] CloudFront integration and index.html replication not fully tested

Study progress:
Started foundational training on Amazon VPC (Virtual Private Cloud) as part of AWS SAA certification today. Yesterday I finished the S3 section.

✍️ Entry #005 – S3 Presigned Urls and an idea for my website

📅 2025-07-31

Theoretical insights:
Today I felt a bit tired — the price of studying alongside a full-time job. Still, I’m glad I pushed myself to go through the next lesson. The topic: Presigned URLs for Amazon S3.

Presigned URLs are a powerful feature that allows temporary, controlled access to private objects in an S3 bucket — even for anonymous users, without making the bucket public. They’re especially useful for secure file sharing or download scenarios.

As I want to combine theory with practice, an idea for my Sunday project came to mind: Why not build a private website where users must request access to view the content? Upon receiving the request, I would get a notification and decide whether or not to approve access. If approved, a Lambda function would generate a temporary presigned URL and send it back to the user. If denied — no access.

I ran this idea by mon adjudant, my trusted ChatGPT aide, and the response was encouraging: it’s absolutely doable.

This concept not only deepens my understanding of presigned URLs but also touches multiple AWS services (S3, SNS, Lambda, IAM) — making it a perfect real-world learning scenario.

✍️ Entry #004 – S3 Lifecycle Config & Replication

📅 2025-07-30

Theoretical insights:
Today I studied two related topics in Amazon S3:

a) S3 Lifecycle Configuration

A powerful feature to automate data transitions and deletions based on defined retention rules.
⚠️ Key takeaways for the exam:
- You can only transition from S3 One Zone-IA to S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive — no transitions to Standard-IA.
- A single rule cannot transition to Standard-IA or One Zone-IA and then directly to a Glacier class — minimum durations (30 days) apply before each transition.
- These duration requirements apply only to Lifecycle Rules — CLI, SDK, or Console-based transitions are not affected.

b) S3 Replication

This feature supports both Cross-Region Replication (CRR) and Same-Region Replication (SRR), often used for backup or disaster recovery.
Core aspects:
- You can replicate all objects or a defined subset (using filters).
- Default behavior retains the source account as object owner, unless overridden.
- You can replicate to a bucket in a different account.
- Replication uses an IAM role assumed by the S3 service; data in transit is encrypted via SSL.
- Supported encryption types: Unencrypted, SSE-S3, SSE-KMS (with additional config).
- ⚠️ Replication is not retroactive; versioning must be enabled. Batch replication is needed for existing objects.

Practical work:
None today — I’m a bit exhausted.
However, over the weekend I plan to:
- Set up replication from my SANDBOX bucket to the DEV bucket to ensure backup of my static website.
- Refactor my Pascals Blog Automation Code to detect and upload only modified files, optimizing my S3 deployment routine.

✍️ Entry #003 – S3 Storage Classes

📅 2025-07-29

Theoretical insights:
Today I studied the different Amazon S3 storage classes and how to choose the right one depending on access frequency, criticality, and cost considerations.

Category One – WARM STORAGE (retrievable in milliseconds):
- 🧾 Amazon S3 Standard – for frequently accessed, important data that is not easily replaceable.
- 🧾 Amazon S3 Standard - Infrequent Access – for long-lived, important data accessed infrequently.
- 🧾 Amazon S3 One Zone - Infrequent Access – for non-critical, replaceable data.
- 🧾 Amazon S3 Glacier Instant Retrieval – cheaper storage, instant access, quarterly retrieval.

Category Two – COLD STORAGE (retrievable in minutes to hours):
- 🧾 Amazon S3 Glacier Flexible Retrieval – occasional access, longer retrieval time.
- 🧾 Amazon S3 Glacier Deep Archive – extremely rare access, hours to retrieve.

Bonus:
Amazon S3 Intelligent-Tiering – auto-moves data across tiers based on usage.

✍️ Entry #002 – Encryption Strategies & Basic Static Website Automation

📅 2025-07-28

Theoretical insights:
Encryption strategies are now clearly outlined. I reviewed client-side encryption, SSE-S3, SSE-KMS, and the use of S3 Bucket Keys to reduce AWS KMS request costs. Flashcards on these topics will follow shortly.

Practical work:
I refined my static website and launched this campaign logbook to track daily progress.
A method in VS Code now automatically uploads HTML to S3 – a basic CI/CD pipeline!
Next step: Enable HTTPS via CloudFront and ACM and finalize public access.

✍️ Entry #001 – First Deployment: IAM and S3

📅 2025-07-28

Theoretical insights:
Today I launched the first stage of my AWS campaign: IAM role delegation and S3 bucket setup.
I successfully tested role assumption across accounts using boto3 and uploaded a test object to S3.
Also planning to restrict region access with Service Control Policies and document key takeaways.